Backport: Move release-environments pipeline to be sourced from master

What does this MR do and why?

Part of gitlab-com/gl-infra/delivery#19905 (closed)

In order to make development of release-environments easier by reducing backports and skew of code across stable branches, we want to make it so regardless of GitLab version being deployed to a release-environment, we are always using the child-pipeline setup from master.

This means we can can make changes to the pipeline setup on master, and it will take effect across all stable branches.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• This MR has a severity label assigned (if applicable).
• Set the milestone of the merge request to match the target backport branch version.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:package-and-test-ee job has either succeeded or been approved by a Software Engineer in Test.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).