Always override project config when `override_project_ci` is applicable

What does this MR do and why?

Previously, when a pipeline execution policy used workflow rules that prevented policy jobs from running, the project’s original CI/CD configuration remained in effect instead of being overridden.

With this change, the project configuration is always overridden. This change is more in line with expectations of users migrating from compliance pipelines.

We've received customer feedback indicating that without this, it would mean a significant effort to rework their configuration.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• #489715 (comment 2243351160)
• #489715 (comment 2258802283)
• #489715 (comment 2261399319)

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. Enable feature flag policies_always_override_project_ci
2. Create a project
3. Create a pipeline execution policy with override_project_ci strategy and the following config:

   workflow:
     rules:
       - if: $CI_PIPELINE_SOURCE == "push"
         when: never
       - when: always
   
   include:
     - project: '$CI_PROJECT_PATH'
       file: '$CI_CONFIG_PATH'
       ref: '$CI_COMMIT_SHA'
   
   job:
     script: echo "Via compliance"
   

4. Create .gitlab-ci.yml in the project:

   job:
     script: echo "Via project"
   
   job2:
     script: echo "Via project"

5. Create MR in the project
6. Verify that only MR pipelines were created, no branch pipelines (except the initial one before the MR was created on the branch)

Related to #512123 (closed).