Refactor CI External::Rules to utilize Entry::Include::Rules validations

What does this MR do and why?

Currently, the External::Rules class contains its own validation logic for the includes:rules config. However, it is redundant since we already have a validatable DSL module that performs these validations for us via Entry::Include::Rules and its composable class Entry::Include::Rules::Rule. Moreover, the Entry classes contain the logic for formatting the config values as needed prior to fabricating the rules list.

As such, External::Rules was refactored to utilize the existing functionality in Entry::Include::Rules and remove the need for def validate. The entry validations are executed upon running .compose!. This also enables us to easily support new includes:rules subkeys in the future, and it produces more precise validation error messages.

---

These changes are made behind a Feature Flag: ci_refactor_external_rules

• This FF does not have an actor because the context is not easily passed into the Entry classes.
• Random incremental roll out will produce unstable results. Thus this FF is expected to be rolled out at 100%.

Roll-out issue: #421731 (closed)

Resolves Step 1 of #342209 (closed), which is a prerequisite to supporting the changes subkey in include:rules.

Screenshots

include:rules validation messages are changed:

Example:

include:
  - local: config1.yml
    rules:
      - if: $TEST == 'test'
        when: invalid

Before	After

How to set up and validate locally

You can validate that any CI pipeline with include:rules defined runs as expected. A simple example is outlined below:

1. Enable the feature flag: Feature.enable(:ci_refactor_external_rules).
2. In your Project, create a new file with the following contents:

config1.yml

job1:
  script: echo

3. In your .gitlab-ci.yml, update the contents with the following:

include:
  - local: config1.yml
    rules:
      - if: $TEST == 'test' # false
        when: never
      - exists: 
        - config1.yml # true

control-job:
  script: echo

4. Run the pipeline and observe that job1 is present in the 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 #342209 (closed)