JwtBearerHandler.cs hardcoded "Bearer "

If someone decides to define their own JWT token scheme that does not use the prefix Bearer, but a different custom scheme name there are issues authenticating the JWT Token while utilizing AzureAD.

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

builder.Services.AddAuthentication("MyCustomScheme")
.AddMicrosoftIdentityWebApi(builder.Configuration, jwtBearerScheme: "MyCustomScheme");

/* code removed for brevity */

var app = builder.Build();

/* code removed for brevity */

app.Run();
```

In your controller if you use "MyCustomScheme" to authenticate it will not authenticate the token out of the box because it is not prefixed with "Bearer ", even though you are utilizing "MyCustomScheme ". This is highlighted on line 78 here:
https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/JwtBearer/src/JwtBearerHandler.cs

You can add an event handler to handle this event, and essentially reimplement what is going on in the JwtBearerHandler.cs, but it seems like overkill for a simple rename to the token.

Now if this may not seem appropriate because [RFC 6750 Section 2.1](https://www.rfc-editor.org/rfc/rfc6750#section-2.1) specifies that the standard for OAuth 2.0 is to use "Bearer " + base64Token. But I would argue then that jwtBearerScheme should not exist as an optional parameter in the extension method as the standard for JWT Tokens should never change in [.AddMicrosoftIdentityWebApi(...)](https://github.com/AzureAD/microsoft-identity-web/blob/master/src/Microsoft.Identity.Web/WebApiExtensions/MicrosoftIdentityWebApiAuthenticationBuilderExtensions.cs). Additionally postman will allow you to change the header prefix, the prefix feels arbitrary, so I believe it should be defined by the provided Scheme, not by the linked spec.

Depending on the responses I feel like it could be argued to open this issue on either side, here or in the AzureAD repository. I figured I can start the discussion here to see if I'm missing anything on my side.