Follow up to: #1084

This PR separates access tokens from id tokens, and removes overly-restrictive validation of them. As mentioned in #1084 (comment), the OAuth2 + OIDC specs do not require access tokens to be JWTs. This means that opaque tokens, which have no defined shape, are perfectly valid. Thus, it is a deviation from the spec to require them to be a JWT.

Further, this deviation from the spec blocks real-world use cases without much gain. While it is nice to check token validity on the client, this client-side check is inherently stale (e.g. revocations, TOCTOU diff, etc...). So graceful handling of said invalid token is probably desirable regardless?

Specific example / use-case:

Google uses exactly this opaque access token format. These access tokens can be used to authenticate agains GKE clusters. The current behavior blocks this use case unnecessarily.

I am aware of Google's gcloud kubectl plugin. There are several reasons kubelogin is much preferable, including:

• gcloud plugin dumps tokens in plain text to disk (this is a non-starter tbh)
• kubelogin is useful across many other clusters b/c it is standard OIDC
• kubelogin is much more simple to deal with vs the whole gcloud cli + mass of python deps/components