When developing the initial GitLab CI secrets support with HashiCorp
Vault as the first secret engine, we've choosen to pass the resolved
secrets to job scope as a "file type" variables.

This however quickly became a limitation as some software is unable
to work with this type of the variables nor it can be adjusted
to it. And this adds additional steps that a user needs to define in
the job to make things working.

With this change we're adding a syntax to make this configurable
and we're updating the job payload API structure.

For the full support an updated version of GitLab Runner will be
required. Support on the Runner side is being added separately.

Changelog: added
EE: true

Currently Vault Secrets are using partially hardcoded configuration
for the authentication method. While the Vault server URL and the
role name for JWT authentication method can be configured with the
variables, the authentication method path is hardoced to `jwt`.
This may limit the usability of our solution.

This change makes this value configurable with the `VAULT_AUTH_PATH`
variable (similar to how `VAULT_SERVER_URL` and `VAULT_AUTH_ROLE`
are being used already) and ensures that in case when the variable
is not defined by the user, it will fall-back to the `jwt` value
that we have hardcoded now.

Update `/api/v4/jobs/request` endpoint to include CI secrets
configuration if job has any and the feature is available.

Inject Vault server configuration details to CI secrets API response
when runner is requesting a job. Server details are currently fetched
from CI variables, this will be moved to DB and UI later.

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/28321
and https://gitlab.com/gitlab-org/gitlab/-/issues/218746.