`RequestDelegateGenerator` should use case-insensitive parsing for enum route parameters

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Describe the bug

`RequestDelegateGenerator` should use case-insensitive parsing for enum route parameters.

This has been brought up before, most recently by @aradalvand in #48346, but those previous issues were treated as opportunities for future extensibility, whereas I would like to make the case that this is a ~~bug with user-facing impact~~ well-documented pinch point that should be easy to patch in a post-RDG world.

> _My tinfoil hat thesis is that this is one of those long-lingering, little frictions that causes far more grief than ever gets reported because it's easy enough to work around, but enums are a first-class primitive and they __deserve__ better support out-of-the-box, __especially__ with the advent of RDG for minimal APIs._

## Argument 1: prior art from other primitives with lenient default parsing rules

Enums (unfortunately) didn't receive the same `IParsable` treatment for `net8.0` as other first-class primitives, which means that RDG has to make a choice about which overload of `Enum.TryParse(...)` to call, as opposed to delegating to `IParsable.TryParse(...)`.

But if we look around at how `IParsable` was implemented/delegated for other primitives, we can find examples erring on the side of more lenient parsing rules by default.

For example, here are the first few lines of [the implementation for `IParsable.TryParse(...)`]((https://github.com/dotnet/runtime/blob/a6e4834d53ac591a4b3d4a213a8928ad685f7ad8/src/libraries/System.Private.CoreLib/src/System/Boolean.cs#L246-L295)):

> ```csharp
> public static bool TryParse(ReadOnlySpan value, out bool result)
> {
> // Boolean.{Try}Parse allows for optional whitespace/null values before and
> // after the case-insensitive "true"/"false", but we don't expect those to
> // be the common case. We check for "true"/"false" case-insensitive in the
> // fast, inlined call path, and then only if neither match do we fall back
> // to trimming and making a second post-trimming attempt at matching those
> // same strings.
> ```

While there's nothing to stop anyone from chaotically defining enum members that differ only in casing, it's a broadly respected convention (backed on Roslyn analyzers) for .NET enums to have members whose names differ by more than case.

Further, .NET enums broadly follow the same conventions as other .NET types, meaning the gross majority of (normal) enums in the wild are defined in PascalCase. This means that any use of an enum in a RDG-generated handler will suffer from the unexpected case-sensitivity demonstrated below in [Argument 3]().

_(I anticipate and respect the quibble that this __shouldn't__ be unexpected, since its well-documented, but if minimal APIs are about making .NET easy to work with out-of-the-box, then it's still a problem worth solving.)_

## Argument 2: RDG has enough context to decide when case-sensitivity makes sense

~~The web is case-insensitive.~~
~~The web should be case-insensitive.~~
The web was, is, and always shall be a place of chaos, but we still deserve sensible happy-path defaults.

It makes sense to use case-sensitive enum parsing by default for things like query strings, request bodies, etc. However, it makes much less sense to do the same in places like path segments, headers, etc.

RDG should have enough context available to generate case-insensitive parsing for path parameters without _having_ to do so for non-path parameters.

## Argument 3: the rest of the routing stack treats path segments as case-insensitive

```csharp
var builder = WebApplication.CreateSlimBuilder(args);

var app = builder.Build();

app.MapGet("hello/{enum}/world", static (SomeEnum @enum) => Results.Ok());

app.Run();

enum SomeEnum
{
None,
Some
}
```

```console
$ curl -i http://localhost:5000/hello/None/world
HTTP/1.1 200 OK
```

```console
$ curl -i http://localhost:5000/HELLO/None/world
HTTP/1.1 200 OK
```

```console
$ curl -i http://localhost:5000/HELLO/None/WORLD
HTTP/1.1 200 OK
```

```console
$ curl -i http://localhost:5000/hello/none/world
HTTP/1.1 400 Bad Request
```

The real-world question I received today was: _"why is only part of this URL case-sensitive?"_

The answer was immediately obvious, because I already knew better than to use raw enums in route templates, but I still managed to walk right into it for the umpteenth time. _(...and again, I have a sneaking suspicion that I can't be the only one repeatedly stubbing their toes on this.)_

## Culprit

https://github.com/dotnet/aspnetcore/blob/b28c8a3aac6db546489dd519f4706c20c8ad2265/src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs#L323-L335

## Related

- #45590
- #35489
- #48346

### Expected Behavior

```csharp
var builder = WebApplication.CreateSlimBuilder(args);

var app = builder.Build();

app.MapGet("hello/{enum}/world", static (SomeEnum @enum) => Results.Ok());

app.Run();

enum SomeEnum
{
None,
Some
}
```

```console
$ curl -i http://localhost:5000/hello/none/world
HTTP/1.1 200 OK
```

```console
$ curl -i http://localhost:5000/HELLO/NONE/WORLD
HTTP/1.1 200 OK
```

### Steps To Reproduce

- https://github.com/austindrenski/request-delegate-generator-enum-parsing-case-sensitive

### Exceptions (if any)

_No response_

### .NET Version

8.0.100

### Anything else?

_No response_