Latest authZ iteration

[HaoK]

• Core Auth API now takes list of IAuthorizationRequirements, or policy name.
• Overload that takes AuthorizationPolicy instance moved to extension method.
• Remove HttpContext from API and replace with ClaimsPrincipal instead
• Add Operation requirement
• Base AuthenticationHandler now automatically converts 401 to 403 if authenticate was called
• Add Sync overloads
• Add ClaimsTransformationOptions (TBD where to use this)

Fixes #132
Fixes #116
Fixes #11
Fixes #117
Fixes #134

cc @lodejard @blowdart @yishaigalatzer @Tratcher

[Tratcher]

This approach easily breaks down with any of the auth middleware that change challenges to redirects (Google, FB, MS, Tw, OIDC, WsFed, etc). Consider:

• The auth middleware produces the identity, but then it does a client side redirect and preserves the identity via a cookie.
• On the next request it is the cookie auth middleware that will set _authenticateCalled.
• If authorization fails and issues another challenge then a few different things could happen:
  • If the challenge is a general 401 without specifying an auth type and any of the redirecting middleware are Active, then the first Active middleware will redirect the request and you're stuck in an infinite auth loop just like before.
  • If the challenge is a specific to an auth type then the middleware doesn't even have to be active, it will always redirect the request and you're stuck in an infinite auth loop just like before.
• So for this to work you have to avoid both of the above by either:
  • Issue a general challenge and have all the auth middleware set to Passive
  • Issue a specific challenge for cookie auth

[Tratcher]

One related note: It's quite strange for cookie auth to issue 403s if it's set up to handle 401s by redirecting to a login page. Wouldn't it make more sense for it to redirect to an Access Denied page instead?

[HaoK]

Removing 401/403 changes and handling that in a different PR

[HaoK]

Merged 5094b85