Add experimental feature to enforce PEP on child pipelines

What does this MR do and why?

This MR introduces an experimental feature that allows Pipeline Execution Policies to be enforced on child pipelines when the experiment :enforce_pipeline_policy_on_child_pipelines is enabled.

Problem

Currently, Pipeline Execution Policies are not enforced on child pipelines because they are classified as "dangling sources" - pipeline events that don't directly affect the ref CI status. This architectural decision was made to maintain clean separation between parent and child pipeline responsibilities.

However, customers have requested the ability to enforce compliance and security policies on child pipelines as well, since:

• Child pipelines can build and deploy applications independently
• Child pipelines can download external code or clone other repositories
• Security scanning in parent pipelines may not cover what's actually built/deployed in child pipelines

Solution

This MR adds an experimental feature that allows selective enforcement of Pipeline Execution Policies on child pipelines while maintaining backward compatibility.

Key Changes:

1. Modified policies method to use source_allowed? for more granular control over which dangling sources should be excluded
2. Added source_allowed? method that implements experiment-based exclusion logic specifically for parent_pipeline sources
3. Added policies_with_child_pipeline_enforcement_enabled method selects applicable policy where the experiment is enabled
4. Comprehensive test coverage for the new experimental functionality
5. Maintained backward compatibility - existing behavior is unchanged unless the experiment is explicitly enabled

Usage

To enable this feature, users need to add the experiment configuration to their Pipeline Execution Policy:

experiments:
  enforce_pipeline_policy_on_child_pipelines:
    enabled: true

When this experiment is enabled on any policy in the project, child pipelines will have Pipeline Execution Policies enforced, allowing compliance and security jobs to run in child pipelines.

Architecture

• Selective Enforcement: Only parent_pipeline sources are affected by this experiment. Other dangling sources (like webide, ondemand_dast_scan, etc.) continue to be excluded regardless of the experiment setting.
• Policy-Level Control: The experiment is checked at the policy level. Policies can opt-in for the experiment enabled and only those will be applied in the project child pipelines.
• Backward Compatible: Default behavior remains unchanged - child pipelines are still excluded unless explicitly enabled.

Related issues

Closes #466092

References

• Pipeline Execution Policies Documentation
• Parent-child pipelines Documentation

Screenshots or screen recordings

Inject mode	Override mode	Experiment disabled

How to set up and validate locally

1. Create a project with Pipeline Execution Policies configured
2. Set up a parent-child pipeline configuration:

   # .gitlab-ci.yml (parent)
   trigger-child:
     trigger:
       include: child.yml
   
   # child.yml
   child-job:
     script: echo "child pipeline"

3. Enable the experiment in the policy configuration:

   experiments:
     enforce_pipeline_policy_on_child_pipelines:
       enabled: true

4. Trigger a pipeline and verify that policy jobs run in both parent and child pipelines
5. Add a child pipeline also to the policy configuration and verify that it doesn't run recursively
6. Disable the experiment and verify that policy jobs only run in the parent pipeline

MR acceptance checklist

This MR has been evaluated against the MR acceptance checklist:

Test Scenarios Covered

• ✅ Child pipelines excluded by default (existing behavior)
• ✅ Child pipelines included when experiment is enabled
• ✅ Other dangling sources remain excluded regardless of experiment
• ✅ Multiple policies with different experiment settings
• ✅ Both strategies work correctly with child pipelines
• ✅ Child pipeline triggered by the policy doesn't spawn another child pipeline
• ✅ Performance: no impact when experiment is disabled

Author's checklist

• Feature flag/experiment added appropriately
• Tests added for new functionality
• Documentation is not required for this experimental feature
• Changelog entry added (Changelog: added)
• EE feature properly marked (EE: true)