Enable stable releases for gitlab_templates and enable self-testing of this project

Goals

1. Right now users of this template hard code 1.0.x branch in several places. Ideally they would use stable releases of this project for all the reasons we use them elsewhere. This MR accomplishes this by having users pull down the ref that we specify in an a new instance variable called _GITLAB_TEMPLATES_REF (a better name is welcome). We can change that ref whenever we want people to start using a new version. We have to use an instance variable instead of the usual "make a new release of gitlab_templates" because the include keyword in Gitlab CI doesn't allow for variables. See https://gitlab.com/gitlab-org/gitlab/-/issues/219065 for details - the issue is not resolved IMO, despite its status. This instance variable is a super minor inconvenience so I wouldn't sweat it.
2. Projects that want to test out upcoming features in gitlab_templates can override _GITLAB_TEMPLATES_REF in their project. Thats a great way for projects to give us early feedback.
3. This MR adds self-testing of our CI template. The approach is that MRs trigger a multi-project pipeline in a testing module's project. If that pipeline passes, we can be more certain that the MR is correct. We can even test in multiple downstream projects to get better coverage. For now the MR triggers into the Akamai project because I've set that one up with the latest .gitlabci.yml. Lets switch to other project(s) once those are updated. View this MR's Pipelines to see this self-testing. Multi-project pipelines have a cool web UX where you can watch them run even as they jump into the other project(s). This is an amazing Gitlab CI feature.
4. By enabling multi-project workflows, we unlock a key feature for ecosystem modules. For example, search api module do a refactor MR and then run downstream pipelines on search_api_solr and facets and so on. Same for group, webform, ctools, etc.

Notes

• Before merge, create a new instance variable _GITLAB_TEMPLATES_REF=1.0.x (not masked, not scoped, not restricted to protected branches). When we want to start pinning users of this project to a stable release, change the variable's value to 1.0.0 or a given SHA1 (for example).
• Self testing currently requires an admin to approve the multi-project pipeline. This is because the MR author may not have permission to run pipelines in the downstream project.