Move CI config loading to dedicated module

Context

Historically, CI config files have been loaded using Gitlab::Ci::Config::Yaml.load!. However, we recently introduced CI headers and CI inputs, which are loaded by combining Gitlab::Ci::Config::Yaml.load_result! with External::Interpolator. The logic that manages the returns from load_result! and Interpolator lives in External::File::Base, so it can only be used to interpolate configurations loaded through the include keyword.

The refactor being tracked in #409846 (closed) aims to complete 2 objectives:

1. Make it possible to parse CI headers and interpolate inputs in every location where we load CI configuration files
2. Make it easy to load CI configurations by creating a single source of truth that handles both loading YAML and interpolating the loaded YAML

What does this MR do and why?

This MR is the first MR for #409846 (closed), which aims to create a single source for loading CI configuration YAML files.

• It moves the CI config loading logic into a dedicated Gitlab::Ci::Config::Yaml::Loader class. In the next MR we'll be refactoring this class to make it easier to check whether the loaded YAML is valid, read errors from the loading process, and add logging
• It also moves the CI config input interpolator from the External module to the Yaml module - since we'll be interpolating inputs anywhere we load CI configs, it makes sense to put Interpolator in a more generic namespace

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 #409846 (closed)