Extend OAuth provider to OIDC

Proposed change

Extend JupyterHub's internal OAuth 2.0 implementation to a full OIDC provider. This mainly means a few (mostly) small changes:

1. add .well-known oidc endpoints
2. enable JWT signing with keys (means another persistent server-side credential, like the cookie secret or cryptkeeper key)
3. support id tokens
4. (maybe?) migrate access tokens to JWT (optional, and also hardest)
5. (maybe?) add more user fields (#4780)

We don't have to use JWT for access tokens in OIDC. Existing opaque access tokens are fine, and would be simpler.

The positive effect of JWT for access token is that clients could authenticate with access tokens without any requests to the Hub, because a JWT contains scopes, expiry, etc. That would completely remove the Hub from single-user access, rather than make it an infrequent endpoint whose responses are cached for a time. The only responsibility of the Hub would be:

1. token revocation (not very easy, basically means we have to keep the checks we currently have, or push revocation notifications)
2. dynamically resolved scopes (i.e. inherit), which we could still resolve as we do now.

Downside of using (or at least requiring) JWT access tokens is that deployments couldn't really pre-issue access tokens, since opaque random secrets wouldn't be valid anymore. That would be a user experience problem we'd need to address somehow.

Alternative options

Don't do this!

Who would use this feature?

Mostly internal, but services that authenticate with jupyterhub can use existing oauth machinery. Nice thing about oidc is you often need just one URL of config and everything else works, as access url, token url, etc. are all encoded in a .well-known endpoint.