Since commit 313ea361 (CMake: Use FindPython instead of
FindPythonInterp to build CMake itself, 2022-04-21), CI jobs on some
Windows hosts have been finding Python via the Windows Registry.
Explicitly disable the registry search so that the CI jobs find the
Python that we download and put in the PATH inside the job.

Previously the qthelp-format release documentation on `cmake.org` was
built manually.

This was previously added in a custom branch for building the
cmake.org reference documentation.

A release pipeline is always created by manual execution of a pipeline
schedule.  Require the initial pipeline jobs to be started manually too
so that we can later add separate components to play separately.

Use the job stage to distinguish upload jobs instead of an
explicit variable.

Ensure that the upload destination is not empty.

Redefine the `CMAKE_CI_PACKAGE` pipeline schedule variable to
indicate whether it is for a development version (`dev`) or a
release version (`v[0-9]...`).  Use this to automatically turn
package upload jobs on or off without having to edit the jobs
in `.gitlab-ci.yml` for release branches.

The template is used to upload both source and binary packages.

This enables the `JavaExportImport` test in CI.

In commit f9526f39 (ci: Add bzr and p4 to Debian and Fedora base
images, 2022-02-21) we checked the SHA-256 hash of the Perforce binary.
However, content at the download URL has changed in just the last few
weeks, so we cannot consider it stable.

The `native` architecture compiles for the host's GPUs, but our CI jobs
may may run on hosts with GPUs newer than supported by their version of
the CUDA toolkit.  Add an undocumented environment variable to tell
CMake to clamp the native architecture to that supported by the toolkit.

Without this, we may try to compile for architectures not supported by
the CUDA Toolkit, which fails.  Since commit d1b48bfa (CUDA: Add
support for CUDA_ARCHITECTURES=native, 2022-03-04), our CUDA 9.2 CI job
fails when it runs on a CI host with a GPU architecture newer than that
CUDA 9.2 supports.  Clamping the architecture level fixes that.

Do not document this clamp behavior publicly, at least for now.
Users can be responsible for building with a CUDA toolkit recent
enough to support their host's GPUs.

Issue: #22375

Apply the rules from commit ff72dbfb (gitlab-ci: configure rules to
enable continuous builds of staged MRs, 2020-09-30, v3.19.0-rc1~70^2~1)
and commit 71665c8c (gitlab-ci: Clarify conditions enabling jobs for
continuous build of stage, 2021-05-05, v3.21.0-rc1~218^2) to dependent
jobs too.

Compute it early enough to use in the configure step.

The script is a standalone ctest script that runs all steps.
It can be used for more than just external tests.

The latter follows our convention for other variable names.

The Swift compiler is too big to put in the Debian base image,
so download it in this specific job instead.

The actual compiler is too large to put in the base image.
Install its dependencies so we can download and run it in a job.
Note that Swift binaries are only available for `x86_64`.

Also clean up more temporary files.

Avoid relying on heuristics to enable these tests.
Be sure they run in CI where expected.

Perforce does not provide binaries for `aarch64`, so leave it out for
that architecture.

Fedora now packages `breezy` instead of the original `bzr`. Note that
breezy does not have the xmloutput plugin needed for `bzr log --xml`.
This is also why commit 1972a755 (Tests: Drop CTestUpdate.BZR test
check for xmloutput plugin, 2022-02-04) observed that there is no
`bzr xmlplugins` command.

Extend the change from commit 840fa28d (ci: Explicitly disable Java
tests on Windows, 2021-12-16) to cover Borland and Open Watcom builds.

Extend the change from commit 840fa28d (ci: Explicitly disable Java
tests on Windows, 2021-12-16) to cover LLVM/Clang builds on Windows too.

Add jobs covering the `clang-cl` front-end with Ninja and NMake.
Add a job covering the `clang++` front-end with Ninja.

Previously we used a complicated heuristic to decide whether or not to
run the MFC test, but it sometimes decided incorrectly to run the test.
Since that was first written, we have developed a convention for other
tests to enable them via undocumented cache entries that are added only
on machines known to meet the tests' requirements.  Do that for MFC.