When running a pipeline on an integration branch in `cmake/cmake`, delay
the lint jobs just as much as all the others.  This avoids starting them
unnecessarily during a sequence of merges over a short time range.

To avoid starving test jobs, the build jobs should also back off if
there is a lot of machine load.

CMake's test suite is sensitive to machine load and can cause spurious
timeouts. To acknowledge this, prevent CTest from spawning tests into a
busy machine.

These jobs are self-contained and so can be re-run on their own to
produce a whole new submission to CDash.  Tell CDash when each
submission is done so re-running a job replaces results rather than
accumulating them.

The 16.8 and 16.9 toolset numbers vary only in their third component.
Use CMake 3.19.7 for three-component toolset version specification
support.

The 16.8 and 16.9 toolset numbers vary only in their third component.
Use CMake 3.19.7 for three-component toolset version specification
support.

The Sphinx build is mostly serial and takes a long time.  All our CI
pipelines (packaging, integration branches, merge requests) have a
dedicated job for the Sphinx build.

For now, leave these jobs out during merge requests.

This makes room for future equivalents for other architectures.
The packaging jobs produce universal binaries, so leave them as-is.

Our custom build includes a patch to avoid server startup timeouts.

The upstream release includes binaries for the architectures we need.
However, the binaries do not have execute permission in their tarballs,
so add it explicitly.

It is a universal binary for both `x86_64` and `arm64` architectures.

Use `linux_release` in names associated with building or testing
release-style binaries.  Add a `.linux_package` helper to adjust
the release binary build behavior for package-specific jobs.

Avoid requiring Windows CI hosts to have WiX installed.

Invoke-WebRequest uses a progress bar by default, but we have no
interactive session anyway.  Turn it off to speed up downloads.

In order to support modern macOS features like Dark Mode, we need to use
Qt 5.15, which requires macOS 10.13.  However, we still want to support
macOS 10.10 as well, for which we need to use Qt 5.9.  Build separate
macOS packages for these use cases.

Fixes: #21606
Issue: #20825

Upload binaries to `cmake.org` through its own name rather than
through the `public.kitware.com` alias.

Backport the upstream Qt patch [1] to link Qt binaries using the
`-isysroot` flag instead of `-Wl,-syslibroot`.  This is needed so that
the binaries have a SDK version set, which is needed for runtime
validation on modern macOS versions.

[1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=6387138a7991b4588639dc48847f175b5afaff84

Update our deployment target to macOS 10.10.
This is required by Qt 5.9.

Fixes: #21565
Issue: #20825

It is not compatible with building for multiple architectures.