Consider using dynamically generated configuration file to make our CI config testable and more concise

In %12.9 there was a new feature released that allows to dynamically generate a CI config and trigger a child pipeline with this config file:

• https://docs.gitlab.com/ee/ci/parent_child_pipelines.html#dynamic-child-pipelines
• https://docs.gitlab.com/ee/ci/yaml/#trigger-child-pipeline-with-generated-configuration-file

We should consider using this to:

• Reduce the size of our configuration (e.g. all the rspec * jobs combinations could be dynamically generated with a Ruby class.
• Allow the CI config to be testable and ensure it's what we expect in all the scenarios that we support (stable branches, auto-deploy branches, MRs, master, changes-dependent jobs etc.).

@gl-quality/eng-prod WDYT?