Allow specifying exact authentication schemes in AuthenticationMiddleware.

## Background and Motivation

I believe there are many different web applications that support more than one authentication mode as default like "if there is an API-key specified, use it, otherwise fallback to cookies". I had such services in development and had an urge to know current user for logging purposes before authorization takes places and cancells requests with 403. It instantly comes to mind that best place for such middleware is between `app.UseAuthentication()` and `app.UseAuthorization()` steps, but the main problem is that you can specify multiple default authentication schemes only for authorization scheme, i.e. authentication step can handle only single authentication scheme(cookies in our case), while API-key is considered only on authorization step.

## Proposed API

The idea is to allow specifying exact list of authentication schemes in middleware so they are handled in same way as they are handled in authorization.
```diff
namespace Microsoft.AspNetCore.Builder;

public static class AuthAppBuilderExtensions
{
+ public static IApplicationBuilder UseAuthentication(this IApplicationBuilder app, params string[] schemes);
}
```

## Usage Examples

```csharp
app.UseAuthentication("api-key", "cookies");
```
In given case this middleware should first challenge "api-key" scheme. If it succeeds, then step is finished, otherwise fallback to "cookies". This overload is not supposed to consider default authentication scheme since all schemes are specified explicitly, i.e. if default authentication scheme is "jwt", then only "api-key" and "cookies" are used, "jwt" is ignored since it is not specified. If default scheme is among the specified schemes, then it should be applied exactly in order as it is specified in schemes list. I.e. being a default scheme doesn't interfere in any way with this middleware.

Also this approach should work better with branched middleware chains since you can specify exact auth scheme to reach them. Like in main branch you use scheme "cookies", for health or prometheus branch you use scheme "api-key". Current approach doesn't support any configuration for middleware.

## Risks

Since this overload is optional and new, it is not supposed to break anything.

Start with the AuthenticationMiddleware and the UseAuthentication extension point named in the issue, then trace how the existing authentication step selects a scheme. Define the overload's ordered fallback behavior, including explicit schemes overriding defaults, and verify that existing no-argument behavior remains unchanged.

Written by the indexing model from the issue text.