Add runners.configOverride mode to skip registration

What does this MR do?

Adds a runners.configOverride value. When set, the supplied content is written verbatim as the runner's config.toml (with tpl interpolation) and the chart skips gitlab-runner register entirely.

In override mode:

• No register call on pod boot — no GitLab API dependency, no token-exchange retries, no in-place re-writes of the config file.
• config.template.toml, register-the-runner, and the set-session-server-* scripts are not rendered.
• runnerRegistrationToken / runnerToken are not required; the auth token lives in the TOML (or is injected via extraEnv / extraEnvFromRefs / secrets).
• runners.config, runners.configPath, and the global-section flags (concurrent, checkInterval, logLevel, sessionServer, …) are ignored — the supplied TOML is the single source of truth.
• Multiple [[runners]] blocks per pod are supported.
• Cache-secret env wiring, preEntrypointScript, and the unregisterRunners preStop hook keep working unchanged.

Usage

runners:
  configOverride: |
    concurrent = 50
    [[runners]]
      name = "my-runner"
      url = "{{ .Values.gitlabUrl }}"
      token = "glrt-xxxxxxxxxxxxxxxxxxxx"
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "{{ .Release.Namespace }}"
        image = "alpine"

Why was this MR needed?

Addresses point 3 of !536 (comment): !536 (comment 3171581983)

The current per-pod-boot gitlab-runner register --template-config … flow is largely vestigial now that runner authentication tokens are minted out of band. It still hits the GitLab API on every boot, drops/garbles unsupported template params, and only supports a single runner per pod. For users who already have an auth token, configOverride is an opt-in escape hatch: bring your own config.toml, the chart mounts it and execs gitlab-runner run.

Default behaviour is byte-identical when configOverride is unset. Points 1 and 2 of the same comment (deprecating register on the default path, retiring protected / runUntagged / etc.) are deliberately out of scope here.

What's the best way to test this MR?

make unit-test   # 53/53 pass, incl. 3 new tests for configOverride
helm lint .

The new tests assert that with runners.configOverride set: config.toml is verbatim, register-the-runner and config.template.toml are absent, the entrypoint skips registration, the set-session-server-* scripts aren't rendered even with sessionServer.enabled=true, and no projected-secrets volume is mounted. The pre-existing deployment-snapshot test still passes without a snapshot diff.

What are the relevant issue numbers?

• Discussion: !536 (comment 3171581983)
• Runner env-var token support: gitlab-org/gitlab-runner!6068 (merged)
• Registration-token deprecation: https://docs.gitlab.com/ci/runners/new_creation_workflow/