[req] Ability to use JWT Role Name as Identity entity alias name

# Problem

There are certain situations where individual claims in the JWT tokens are insufficient at properly identifying a unique identity.

Take [GitLab JWTs](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/#how-it-works) as an example. Each claim in the JWT is a distinct, disparate piece of information about which repo, branch, user, etc. caused the CI job to spawn.

This makes it impossible to have granular Identities aliased to these JWTs. The finest grain Identity we can have in this example is `project_path` which severely limits the usefulness of the `bound_claims` restrictions that can be accomplished with roles. Building on this example, if we wanted to associate an identity with CI jobs in a certain repo but only on the `main` branch, that is impossible.

This becomes increasingly difficult in Vault enterprise where the Identity engine is used to grant permissions within child namespaces. In order to solve this in the short term, we have mounted per-namespace auth backends and are having users create their own roles within their namespace-local backends which is potentially detrimental to our client count (core licensing metric).

# Proposed Solution

Allow for the name of the role used during authentication to be used as the Identity entity alias name.

This would allow us to leverage the powerful bound_claims restrictions and map them directly to an Identity.

For example, we could create a role like:
```json
{
"name": "myteam.myproject.production"
// add some boolean to toggle this behavior
"role_name_as_entity_name": true
"bound_claims": {
"project_path": "myteam/myproject"
"ref_protected": "true",
"environment": "production",
"environment_protected": "true"
}
}
```
Then an Identity:
```json
{
"name": "gitlab--myteam-myproject--prod"
}
```
And an alias:
```json
{
"name": "myteam.myproject.production",
"canonical_id": "id-of-entity",
"mount_accessor": "accessor-of-jwt-backend"
}
```

At this point, users are free to create internal groups (with the entity above as a member) in their namespaces with whatever policies they need. The auth mount can live in the root namespace, have access to any number of children, and we don't have to mount an auth backend per-namespace anymore.

The issue does not name implementation files or tests. Start by locating the JWT role authentication flow and the code that creates Identity entity aliases; determine how an opt-in role-name alias would interact with bound_claims and namespaces. Done means the role name can be used as the alias name without changing existing behavior when the option is disabled, with tests covering the new option.

Written by the indexing model from the issue text.