3-level CI build system for LALSuite

Description

This MR implements a 3-level CI build system for LALSuite, following #559 (closed).

1. Push events trigger a minimal CI pipeline which runs some basic build checks. The idea is that this pipeline will likely be run many times as a feature branch is developed, so it should minimize run time and resources. The follows CI jobs are run:
   1. A basic package-level build which build LALSuite libraries in sequence from the tarballs. This replaces the RPM/Debian/Conda package builds for push events only, since at this stage we only care whether LALSuite builds, not whether the packaging is working.
   2. Top-level build
   3. Documentation build
   4. Lint checks
2. Merge requests trigger the full CI pipeline, which previously ran only as part of the nightly build. The idea is to avoid the perennially tedious situation where changes are merged into LALSuite, after the normal build passes, only for the nightly build to then fail some time later, which then requires people to go back and fix the broken build and/or revert changes (see e.g. !1997 (merged), !1999 (closed) for 2 recent examples) which wastes valuable person-power. Running the full CI pipeline at merge request time should prevent broken changes being pushed in the first place. (Note the the basic package-level build from the push CI pipeline is not build for MRs, as it's essentially redundant with the RPM/Debian/Conda package builds.)
3. The scheduled nightly build now only runs deployment tasks, although some of those (e.g. updating Docker images) do require some build jobs to be re-run. Generally the nightly build should not run jobs that were not run during merge commits, to avoid the situation described above from occurring. Currently the only jobs in this category are the Koji build jobs, which should be fine as by this point the normal RPM builds will have passed.

(Perhaps in future, we may want to add a ~weekly pipeline which runs the full CI pipeline to test for upstream breakages, for now though I don't think that is necessary.)

If changes are being made that will (or are suspected will) affect the platform/compiler/packaging jobs, once can use special commit messages to includes those jobs in the push CI pipeline; for example, add [ci rpm] to a commit message to run the RPM packaging jobs as part of a normal push. Note that these messages are opposite from the previous [skip ...] messages which excluded jobs; these were billed as most useful for skipping the CI for e.g. documentation changes, which are relatively infrequent, and you then had to add a dozen [skip ...] messages to skip the entire CI build. I think it's more useful to have codes which include extra jobs into the minimal push pipeline which you might want to test before submitting an MR.

The new CI pipeline setup is documented in CONTRIBUTING.md.

I've also tried to minimize the number of jobs with retry: 1, to minimize cases where jobs are being rerun due to build failures. At the moment retry: 1 is only added to

• jobs which AFAICT require external repositories (e.g. yum, apt-get) which might be down, i.e. the RPM/Debian/Conda, upgrade, platform, coverage tests;
• MacOSX jobs, where from memory the CI runners can be a little more flaky than the Linux ones.

I've also used interruptible to denote which jobs can be cancelled when a new pipeline starts, which should also save some cycles. I've currently marked all jobs interruptible apart from MacOSX jobs (due to issues with permission errors; !1743 (merged)) and deploy jobs (which only run nightly anyway).

In order to get the full CI build to pass I've allowed the gcc:12 and upgrade:debian:bullseye to fail; once this is merged it should be more straightforward to get those fixed, as the MR CI pipeline won't pass unless they are fixed.

API Changes and Justification

Backwards Compatible Changes

• This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions
• This change adds new classes/functions/structs/types to a public C header file or Python module

Backwards Incompatible Changes

• This change modifies an existing class/function/struct/type definition in a public C header file or Python module
• This change removes an existing class/function/struct/type from a public C header file or Python module

Review Status

Closes #559 (closed)

cc @adam-mercer @duncanmmacleod