Add `trigger:include` CI YAML syntax to create sub-pipelines

NOTE: CHANGES FROM THIS MR HAVE BEEN MERGED INTO !20930 (merged)

What does this MR do?

Related issue: #16094 (closed)

This MR is a continuation of !20930 (merged) where we changed Ci::CreateCrossProjectPipelineService to allow the creation of sub-pipelines (parent/child pipelines).

In this MR we are allowing the creation of child pipelines via YAML syntax:

Using simple trigger:include:

microservice_a:
  trigger:
    include: config/microservice_a.yml

Using complex trigger:include:

microservice_a:
  trigger:
    include: 
      - local: config/microservice_a.yml
      - template: config/all_microservices.yml
    strategy: depend
  only:
    changes:
      - microservice_a/*

During the processing, we will store the include value in bridge.options as { trigger: { include: [...] } }. Then, when creating a child pipeline we will pass the CI config content as defined in bridge.options.dig(:trigger, :include) as:

include:
  - local: config/microservice_a.yml
  - template: config/all_microservices.yml

and a pipeline will be created on the same project, same sha, same ref but with a structure defined in the input YAML content.

Screenshots

Pipeline page

parent-child-pipeline-alpha

Merge Request page

parent-child-pipeline-mr-alpha

Outstanding issues

We are introducing this change behind a feature flag ci_parent_child_pipelines which will be off by default until we have the following issues addressed (in different MRs):

• Limitations in place: Child pipeline cannot create other child pipelines, trigger:include must have a max number of entries.
• Child pipelines not listed in MR pipelines index and Pipelines index
• Documentation written

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team