CI syntax for Vault managed secrets

What does this MR do?

This MR adds initial support for configuring job's secrets in CI yaml.

The syntax look like this:

deploy:
  stage: release
  secrets:                                   # Top level key to allow adding another secrets manager in the future
    vault:
      db-vault:                              # Arbitrary name, used only to allow usage of multiple vault
                                             # servers and to uniquely identify the entry (so it can be easily
                                             # used with the `extends:` feature of GitLab CI YAML specs)
        url: https://db.vault.example.com
        auth:
          name: jwt                          # Auth method to be used
          path: jwt                          # Auth method path
          data:                              # Any other data needed
            jwt: ${CI_JOB_JWT}
            role: production_db              # Vault role to be used during login, optional, if not provided will be omitted
                                             # and the default role configured for this auth method will be used
        secrets:
          DATABASE_CREDENTIALS:              # ENV variable name to be used to expose the secret
            engine:                          # Secrets engine details
              name: kv-v2
              path: path/to/engine
            path: production/db              # Secret's path
            fields:                          # Fields to be fetched for this secret
              - username
              - password
            strategy: read                   # The only supported strategy for now is `read`

None of the defaults specified in #28321 (closed) are supported at the moment, this will be added in subsequent MR.

The processed config will be returned to the runner (to be implemented in a subsequent MR) where it will be used to fetch the secrets from Vault, see gitlab-runner!2006 (closed).

This will be GitLab Premium feature, the license check will be added in a subsequent MR at the API level so that we can scope to a project.

See #28321 (closed) for more details.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team