Draft: Allow users to customize jwt sub claims

Related to #360592

What does this MR do and why?

This is a re-implementation of community contribution !159485, thanks to @steve.mckay

This MR adds a new attribute to projects, named ci_id_token_sub_claim_components.

This is the initial iteration to introduce and test JWT customization settings. The API and documentation will be addressed in the follow-up merge request.

Project admins can change the value of ci_id_token_sub_claim_components to produce tokens with more or less detailed sub claims - admin authorization will be on the API layer.

The default value of ci_id_token_sub_claim_components is ["project_path", "ref_type", "ref"]. Each element of ci_id_token_sub_claim_components must name a custom JWT claim produced by GitLab, and the first element must be project_path.

JWTs created for id_tokens in CI now use this config to create the sub claim on the token. Each element of ci_id_token_sub_claim_components is formatted into <claim_name>:<claim_value>, joined with :. For the default value this will result in sub claims that reproduce the current fixed format, which looks like project_path:agroup/bgroup/myproject:ref_type:tag:ref:v4.2.0. Custom formatting and static values aren't permitted.

MR acceptance checklist

Issues that need to be addressed:

• Unit Tests
• Improving validation of ci_id_token_sub_claim_components

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Testing token production:

1. Update a project's ci_id_token_sub_claim_components on rails console project.ci_id_token_sub_claim_components = [new_value]
2. Run a build that has id_tokens configured
3. Echo the token (echo $TOKEN | base64 or it will be masked)
4. base64d and verify