Should API Keys be per user?

The enhancement may already be reported! Please search for the enhancement before creating one.

### Current Behavior:
Only Teams have API Keys

### Proposed Behavior:
Users have API Keys

### Benefits
Allowing users to have an API Key simplifies things:
- You always know who is making the request, so better for audit logging
~~You always know who is making the request, so easier for autocreating projects with the right ACL~~
~~You always know who is making the request, so you could set an `owner` for a Project, which is allowed to manager certain things such as the ACL~~
~~API Keys are now personal, so we could show them once to the user and after that hide/mask them~~

I know this enhancement might have to be made in the Alpine framework, but I thought listing/discussing it here whether it would help DT is beneficial.

### Downsides
- Shared api keys for teams are useful when dealing with users coming and going to a company/team.
- Complexity if both team api keys and user api keys are to be supported

No files or tests are identified. Start by tracing the existing team API-key flow and reviewing how the Alpine framework would support user keys; resolve whether both scopes should coexist, including ownership and lifecycle semantics. Done means the supported key model, audit identity, and behavior for teams and users are clearly defined.

Written by the indexing model from the issue text.