Also, changed the default for detected undefined issues to stop program
execution and return a non-zero code.

The baseline is to establish that without being instrumented by
sanitizers, the test programs can both compile an run without obvious
issue.

Put into a subdirectory, and the file/app/test renamed to what is
expected to occur, a data race.

Examples of using an uninitialized value or pointer.

Expand from just a direct leak, to both a direct and indirect leak
example programs.

Turn off leak detection on address sanitizer, to better showcase
address-specific detection and the leak sanitizer.

Change CMake calls for better option clarity, and sanitizer builds from
release to debug builds for clearer errors.

Instead of just the one example that detected the use-after-free, added
a number of new files to detect:
- double free
- out of bounds on global/heap/stack data
- use after free
- use after return
- use after scope

While compiler warnings have improved to detect some of these cases at
compile time, they all do still compile.

Apart from double-free, all of these programs also execute without
issue, highlighting the usefulness of address sanitizer runs.

Easier to find/use sanitizers with the examples.

Update for new ltsc based Windows container images.

When running using the CMake test suite, so far they have been invoked
via the build system, such as `ninja test`, however using the `ctest`
program directly does give some improved control, such as being able to
output verbose content to see the undefined sanitizer behaviour.

When checking for the availability of a sanitizer set, it would only run
`check_cxx_source_compiles` for the full set of flags, and additionally
`check_cxx_compiler_flag` on WIN32.

Now, it performs both checks for all platforms.

The `-fno-omit-frame-pointer` flag is not available with MSVC, so
instead perform a check the flag is available before adding it for
default legacy sanitizer options.

To better test how non-Linux platforms interact with the use of the
legacy path for sanitizers.

When checking for the availability of a sanitizer, it now checks the link
options as well as the compile options.

Each C++ version macro now uses version-specific variables instead of
one general, to help prevent issues when changing versions and the
variable being accidentally being used for a different version across
configurations/generations.

For Windows, add jobs testing the address sanitizer for MSVC, as no
sanitizer is known to work with Clang or Clang-CL.

For macOS, add jobs testing sanitizer works both with AppleClang and
Clang.

While clang has the best support, GCC also supports a number of
sanitizers, so verify via new CI jobs.

The previous sanitizer support was implemented in a very rigid manner,
with the compile options available for each sanitizer type been preset,
and enabling of each sanitizer through a preset variable.

This change makes it so that setting of compile options can be set on a
per-sanitizer-type basis and then added to builds via functions. Use via
the legacy `USE_SANITIZER` is available, but deprecated.

This is also flexible enough to allow overriding of the compile options,
via variables either in-script or passed in via the command-line.

Results of checks for compile compatability are cached, reducing time
on subsequent builds, provided the associated compile options are not
updated.

Checks for sanitizer availability/compatability are no longer platform
dependent. It will check on all platforms.

A mis-named variable made it so no object was linked for LLVM code
coverage builds.

Not installed on Fedora images by default, needs to be explicitly
installed first.

Also fix small formatting issue with prepare-catch.cmake

In addition to the original ability for 'OBJECTS' to import and present
coverage information for shared libraries, it has now been updated to do
the same for detected static library targets.

Analysis tools have been dropped from it since not all tools are
available on all supported architectures.

Previously, the turning on/off clang-tidy, include-what-you-use and
cppcheck was handled by a combination of an option and the use of macros
for specific details. This has meant only straightforward usage was
accomodated.

Rather, there is a desire to be more flexible, to allow for difference
code to be compiled with different options, or to turn on/off tools
altogether for specific scopes.

The options of `CLANG_TIDY`, `IWYU` and `CPPCHECK` have been removed.
Instead, it is up to the including project on when/how to enable these
tools. The ability to 'reset' the tools, to disable them for certain
scopes has been accomodated via the use of `reset_*` macros.

The details as to the commands/calls for clang-tidy/iwyu/cppcheck are
now marked as advanced, so as to not clutter the simplified CMake UI
output.

As always, the variables are still displayed in the advanced mode.

The tools.cmake file included a number of tools, but only implemented
their use just in C++.

This adds their use with C.

No longer have a machine available in the pool.

Fixes ccov-all-export on Windows platform with an if/else split.

Prefixed all code-coverage jobs with the operating system, added Windows
all code coverage jobs.

Add macOS AppleClang/Clang CI jobs

Expand testing to other architectures, with Linux is
amd64/arm64/ppc64le, macOS is amd64/arm64, and Windows is amd64.

When on macOS, if using the Apple-provided toolchain from XCode, also
use the same toolchain for code-coverage. The use of hybrid toolchains
does not go well.

The assimp library now has pkg-config and CMake config files installed
by default, rendering this module script unnecessary.

When cross-compiling, the used emulator will be prefixed to the call.

In addition to the current ARGS multi-value option which appends options
to the end of an executable call, PRE_ARGS instead prefixes items to the
call, to the end for of:
$PRE_ARGS ccov-* $ARGS

Since these files were originally added, the libraries themselves have
added native CMake configuration files that can be used instead.

The only purpose of the job was to create the 'ccov' directory in the
binary directory to store all the generated code coverage files.

Rather than generating the directory at build time using a target,t he
directory is now created at CMake generation time, meaning the build-
time target is no longer necessary.

CI attempted to run jobs on riscv64 nodes when opensuse/fedora don't
have supported container images for that architecture.

Infrastructure/CI runners have been restructured.