Inconsistent behavior for selecting output formatter based on Accept header with `ReturnHttpNotAcceptable = true` option set

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Describe the bug

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

builder.Services.AddControllers(options =>
{
options.ReturnHttpNotAcceptable = true;
});

var app = builder.Build();

app.UseAuthorization();
app.MapControllers();
app.Run();
```

```csharp
[ApiController]
[Route("weatherforecast")]
public class WeatherForecastController : ControllerBase
{
[HttpGet]
[Produces("application/json")]
public IActionResult Get()
{
return Ok(new { Result = "ok" });
}
}
```

HTTP response code depends on variant of `Accept` header and its **parameters order**.

1. `Accept: application/json` - returns **200 OK**
2. `Accept: application/json; q=1` - returns **200 OK**
3. `Accept: application/json; charset=utf-8` - returns **406 Not Acceptable**
4. `Accept: application/json; charset=utf-8; q=1` - returns **406 Not Acceptable**
5. `Accept: application/json; q=1; charset=utf-8` - returns **200 OK**
6. `Accept: application/json; charset=utf-8;` - returns **200 OK**

Results 1. and 2. are expected.
Result 3. I assume is fine although UTF-8 encoded response is going to be returned anyway as that is the default.

Result 4., 5. and 6. look like some bug in the header parsing.
As we can observe test cases 4. and 5. differ only in the parameter order for the `application/json` media type and case 4. returns **406 Not Acceptable** while case 5. returns **200 OK**.
Notice with the case 6. there is additional semicolon at the end and it makes it work compared to case 3. which returns **406 Not Acceptable**.

### Expected Behavior

Parameter order for media type most likely should not change behavior.
Semicolon at the end should most likely not change behavior.

Not sure what should happen when there is a formatter configured for `application/json` and client requests this media type but attaches additional parameters (like `charset` or any custom parameter). As far as I know HTTP spec does not clarify how content negotiation should be performed. I assume current behavior of returning **406 Not Acceptable** is ok as we do not configured any formatter for such media type and parameter combination.

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### .NET Version

8.0.400

### Anything else?

ASP.NET Core version: 8