Runner admission controller management API

See the blueprint being updated in this MR Update Runner Admission Controller design to al... (gitlab-com/content-sites/handbook!16358) for background info.

• We need to track admission controllers (AC) in a DB table.
• ACs are identified by their ID in the table.
• AC may have a name in the future.
• ACs are instance-wide. We may have organization/group/project-scoped ACs later but not for now.
• Each AC has 0 or more access tokens for authentication.
• Tokens can be added and/or deleted so that it's possible to rotate a token.
• Tokens do not expire. We cannot force expiration on users if we don't provide a way to automatically rotate the token because that creates toil (we are supposed to solve customer issues, not add to the pile). We must provide an API to rotate a token, which we do.
• There should be an internal API that kas can access to verify AC's token. This API should return the ID of the AC (potentially more info in the future, like authn credentials that kas should use). This is similar to the existing /api/v4/internal/agents/agent{k,w}/agent_info API endpoints.