Move oidc auth into a token manager

[butonic]

This hurts ... but the oidc auth manager does not make sense. I used to store the claims in the context, but with the gateway this was removed. Now, the oidc user manager has no way of resolving the claims, other than trying to do a userinfo lookup ... which the auth manager already did. Furthermore, oidc already uses a token. We should treat it as such.

This PR

• adds a token strategy: bearer that reads the token from thea authorization header and strips the bearer part
• moves the oidc auth logic into a new oidc token manager
• adds a noop token writer. Only the idp writes tokens

This makes a lot more sense and reduces the number of requests significantly if the token is a jwt.

We may want to replace the oidc token with a custom jwt token to convert opaque access tokens to jwt ones. We also need to reflect this in the documentation. In a subsequest PR or commit ....

[butonic]

this is a wrong approach. the idea was to use the gateway as a central authentication step. it will convert whatever cretentials into a jwt token we use inside and pass on to other reva services. the right way is to return a user when authenticating credentials, not only the id.