Draft: POC for triggering Compliance and Project config as child pipelines

What does this MR do and why?

This is a POC for the proposal to internally trigger both the Compliance pipeline and the Project's pipeline as separate child pipelines.

Goals accomplished in this MR:

• The Project pipeline should run regardless if the config file is external or remote.
• The Project pipeline should run without triggering a circular pipeline scenario in which the Compliance pipeline is triggered again.
• The Compliance pipeline should always run first and pass before the Project pipeline is run.
• The Compliance pipeline should run even if the Project does not have a CI config file configured.
• The user should be able to define top-level global keywords (such as stages:) in both the Compliance and Project config files.

Related to Backend: Running a pipeline in a project with a... (#393960)

How to set up and validate locally

Initial setup:

1. Create the following Compliance YAML file in a project. Here I will be referencing this project as Project 1, located at /group-a/project-1.

compliance1.yml

compliance1-job:
  script: echo

2. At the project's Group level, set up a Compliance Framework pointing to the Compliance file in Project 1. Call it Compliance1.

3. In another project (Project 2), update the .gitlab-ci.yml file with the following contents:

project2-job:
  script: echo

4. Apply the Compliance Framework label Compliance1 to both Project 1 and Project 2.

Now we will test a couple cases to validate the POC.

Case 1: Project has an external config file

1. In Project 1, set the config file to be the one from Project 2. (Ref: Specify a custom CI/CD configuration file)

2. Run the pipeline in Project 1. Observe that both the Compliance and Project 2's config files are triggered as child pipelines.

3. Additionally, we can observe what happens when the Compliance pipeline fails. Update the compliance1.yml file in Project 1 with the following:

compliance1-job:
  script: exit 1

4. Run the pipeline in Project 1 again. Now observe that the project's pipeline is not triggered.

5. Revert the change to compliance1.yml to prepare for the next example.

Case 2: Project does not have a config file configured

1. Delete .gitlab-ci.yml in Project 2. Note that Project 2 should have the default local configuration file path (.gitlab-ci.yml).

2. Run the pipeline in Project 2.

3. Observe that with Auto DevOps enabled, the project pipeline triggers the Auto DevOps templates.

4. If you disable Auto DevOps, observe that it only runs the Compliance pipeline.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #393960