AuthZ 2.0 Improve failure scenarios + [401 vs 403?]

[HaoK]

The two somewhat related scenarios we are trying to address:

1. How to determine which requirements failed and easily display them
2. Remove the automatic challenge behavior/logic and make 401/403 more explicit (somehow)

How things work today:

1. bool IAuthorizationService.AuthenticateAsync only returns sucess or failure, its impossible to deduce what caused the failure.
2. See AuthorizeFilter.OnAuthorization.

Basically the caller is responsible for building up the ClaimsPrincipal for authorization. There's a hint on the policy via the AuthenticationSchemes which the caller should use for Authentication and merge together for the final principal. The first important point here is that we no longer know what claims came from which authentication scheme (claims transformation also is a wrinkle so even if only a single scheme was used, there's no guarantee).

Next the IAuthorizationService checks the requirements from the AuthorizationPolicy against the merged principal and if it fails, we challenge all of the schemes. So today the Challenge(401) vs Forbid(403) behavior is completely left to the implementations of the authentication middleware for how they respond to the challenges. The default implementation of that behavior is to return 401 if the scheme does not have an authentication ticket, and 403 if it does (i.e. if a cookie/bearer token exists, or the remote identity already has a signed in identity)

Ideas for improvement:

1. The needed change is to enable getting back a new AuthorizationResult that contains the failed requirements, that should be sufficient to enable callers to display error information. We should also add some mechanism to describe the requirement failure to make it easy to generate this data, maybe a AuthZFailureDescriber<TRequirement>?

2. We'd like to try and eliminate the ChallengeBehavior.Automatic and change the meaning of Challenge to always result in Unauthorized/401 behavior. And Forbid should be called explicitly instead of something that happens to some challenges. Callers like AuthorizeFilter would need to have enough information to make the choice.

Scenarios to target:

1. [Authorize("Administrator")] protects an action, when a regular user hits the action, an error page stating that the user was forbidden because he was either not in the Adminstrator role, or did not have the Administrator claim (depending on how the policy was implemented)

Related issues that should also be addressed:

aspnet/Diagnostics#316
#860
#872
openiddict/openiddict-samples#33 (comment)

cc @blowdart @Tratcher @Eilon @davidfowl @PinpointTownes

[HaoK]

per #860 consider adding verbose logging for successful requirements