Do not block a job that requires approval unless a deployment is present

What does this MR do and why?

Do not block a job that requires approval unless a deployment is present

When deployment approvals are configured for an environment, jobs that deploy to the environment are held in a manual state until the required number of approvals has been met.

Only jobs that actually create deployment records should be held in this state, as approval is not required when the job only accesses the environment (for example, to collect metrics) and does not modify it.

This behaviour is controlled by the environment.action keyword. The default is start, which does create a deployment. The other options do not create deployments.

As this is a breaking change, it cannot be released on GitLab.com until %18.0. It is behind the prevent_blocking_non_deployment_jobs feature flag, which is disabled by default. The feature flag will be rolled out on GitLab.com during an %18.0 breaking change window.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

1. Configure your GDK with a runner, and a Premium/Ultimate subscription.
2. Create a project, and create a protected environment, adding your user/role as an allowed deployer.
3. Add a CI template that creates both deployment and non-deployment jobs for your environment, for example:

    stages:
        - pre
        - deploy
        - post
    
    pre-deploy:
        stage: pre
        script: echo 'pre-deploy'
        environment:
            name: production
            action: prepare
    
    deploy:
        stage: deploy
        environment: production
        script: echo 'deploy'
    
    post-deploy:
        stage: post
        script: echo 'post-deploy'
        environment:
            name: production
            action: access

4. Start a pipeline, and observe that the pre-deploy and post-deploy jobs are awaiting manual action, even though they don't require approval (this is the existing behaviour).
5. Enable the prevent_blocking_non_deployment_jobs feature flag.
6. Create a new pipeline, and this time observe that the pre-deploy job starts immediately. The post-deploy job will also start as soon as you approve the deployment.

Related to #390025 (closed)