Add TryParse support for route parameters.

[mitchdenny]

This PR adds TryParse support to route parameters. Uses the same test data as RDF. Currently waiting for this PR to be approved then I'll rebase on main to solve an outstanding indentation issue.

#46928

[captainsafia]

Can you explain the need for the null suppression operator here and elsewhere?

[mitchdenny]

It probably isn't ideal. This is the situation that led to it:

Task RequestHandler(HttpContext httpContext)
{
    var wasParamCheckFailure = false;
    var context_local = httpContext;
    // Endpoint Parameter: routeValue (Type = System.Net.IPEndPoint, IsOptional = False, IsParsable = True, Source = Route)
    if (options?.RouteParameterNames?.Contains("routeValue", StringComparer.OrdinalIgnoreCase) != true)
    {
        throw new InvalidOperationException($"'routeValue' is not a route parameter.");
    }
    var routeValue_raw = httpContext.Request.RouteValues["routeValue"]?.ToString();
    if (routeValue_raw == null)
    {
        wasParamCheckFailure = true;
    }
    var routeValue_temp = routeValue_raw?.ToString();
    if (!global::System.Net.IPEndPoint.TryParse(routeValue_temp!, out var routeValue_parsed_temp))
    ...

We check that RouteParameterNames contains routeValue and if it doesn't we throw. But then we get the value out of the collection, but because the compiler can't guarantee that its not null I used the ?.ToString() approach. So from the compilers perspective routeValue_raw and routeValue_temp could both be null.

I could adjust the if block containing TryParse to do a null check to avoid the usage of the null suppression but I'm not sure if adds much value. I guess I am assuming that TryParse implementations will return false when s is null. The fact that TryParse implementations are typically in the form TryParse(string? s, ....) makes me think that is a fair guess.

Basically, all those TryParse invocations could be dealing with a null input at some point.