support: honor scopes for JWT auth (hasura v2)

### Is your proposal related to a problem?

Some identity services provide scopes, for which we can use it to leverage and determine allowed roles in turn for Hasura RBAC permission system. This is critical for M2M authorization flows and scopes are part of [OIDC spec](https://openid.net/specs/openid-connect-core-1_0.html).

Sample token example:
```json
{
"sub": "...",
"aud": "https://example.com/service",
"nbf": 1695670063,
"scope": "openid profile email admin",
"iss": "https://example.com/",
"exp": 1711222063,
"iat": 1695670063,
"jti": "...",
"client_id": "..."
}
```

### Describe the solution you'd like

Just like we have [claims_map](https://hasura.io/docs/latest/auth/authentication/jwt/#claims_map), we can have one for honoring scope where we can assign session variables for particular scope which would drive the authorization further in Hasura.

### Describe alternatives you've considered

One suggestion on top of my mind is to use [Actions in auth0](https://auth0.com/docs/customize/actions/actions-overview) where you can write business logic to extract scopes and create a mapping for claims there, and you can pass claim with x-hasura-allowed-roles or x-hasura-default-role mapped to admin. For ref - https://auth0.com/docs/customize/actions/write-your-first-action#add-custom-logic
```js
module.exports = function(client, scope, audience, context, cb) {
var access_token = {};
access_token['https://foo.com/claim'] = 'bar';
access_token.scope = scope;
access_token.scope.push('extra');
// you can write your business logic to include admin role in claim map, for example - https://hasura.io/jwt/claims
cb(null, access_token);
};
```

In your action, you can modify to check if scope string contains "admin", and if yes, then pass `x-hasura-allowed-roles : ['admin']` value under `claims_map` . You may modify it to your needs as you said you wish to honor other scopes as well. In a nutshell, mapping the scope to that role and adding the admin secret (in header) is the objective for this approach.

Then you can attach this [action to particular flow](https://auth0.com/docs/customize/actions/write-your-first-action#attach-the-action-to-a-flow) (like M2M). This can solve your use case for extracting scopes and then determining allowed roles.

Start with the sample JWT in the issue and the linked claims_map documentation, then compare the proposed scope mapping with the OIDC scope reference. Done means a defined way to map token scopes to session variables that drives Hasura role authorization, with the behavior and configuration clearly documented.

Written by the indexing model from the issue text.