CMake-coding-style isn't C++-coding-style.

The target name for a module is annoyingly long and hard-to-read. Set a
parent-scope variable with a nicer name to the full target name.

-extensions won't build unless the CMake modules are (somewhat) self-contained.

If set to *ON*, then the dependencies for these two are required
(e.g. QtXml and/or AppStreamQt).

- add a CMake helper for finding variations of AppStreamQt
- adapt packagechooser and packagechooserq
- adopt a slightly more modern CMake style here

Allowing aliases and not using a canonical name for
them (e.g. mapping "view" to "viewmodule") is annoying
since the target name depends on which alias is passed
in to the function. Drop one of the two aliases.

with https://invent.kde.org/system/kpmcore/-/commit/2588d1e796442409a8f95f1777b4f1d89086028a
KPMCore is Qt6 only, so any version from 24.01.75 on is Qt6, no need to check for Qt version this way
add missing NO_CONFIG to summaryq

Misplaced $, and looking for translation sources in the
wrong directory, led to a test-case failure before release.

make kpmcorehelper usable for both kf5 & 6, though no section added yet dealing with set to NOT for Qt6
adjust CalamaresConfig to not be hardcoded to kf5
one more var needed in Variant.h, used in PartitionInfo.cpp
adjust QVariant & QtConcurrent use

- move template QRC file to the module that defines the function
- add parameters to accept more files (prefixes) per language

- On FreeBSD, no KF6 was available
- On KDE Neon Unstable, there are somewhat wonky KF6 packages available
- Adjust CMake to find the KDE Neon versions, then fix the C++ code

This works around older CMakes that refuse to set arbitrary
properties on a target. Instead, use calamares::kpmcore
as the specific indicator that kpmcore was found.

Breaks build of libcalamares, since that needs **something**
regardless of whether KPMcore was found.

- the alias libraries calapmcore and calamares::kpmcore
  are always created; if there is no KPMcore, they handle
  definitions to signal that.
- upstream kpmcore target is the one we should be testing
  to see if KPMcore itself is there (or, use KPMcore_FOUND).

- kpmcore (when used as target "kpmcore") has an interface
  include directory that does not contain the "kpmcore/"
  subdirectory. But the headers it has installed, assume it
  is there (e.g. kpmcore internals use #include <fs/filesystem.h>).
- add an alias at Calamares level that sticks in some more
  includes, adds the relevant WITHOUT_kpmcore when it's
  not there, etc.

- find the dependencies just once
- fix the interface for kpmcore so it can find its own
  includes (this is mostly relevant for Debian)

Consumers of calapmcode couldn't tell if KPMcore was found.
Pass it around as a property of calapmcore, rather than
anything else.

FIXES #2026

Nothing beyond the example module was ever built with the
PythonQt bindings, as far as I can tell. They have been
deprecated, defaulting OFF for over two years now.

QML modules fill the gap with customizable, run-time
interpreted UI and stronger support from the C++ side
of Calamares.

This introduces a stub-implementation (fake) that mimics the
API offered by libcalamares (the library is actually exposed
to Python via Boost::Python, so it doesn't act like a C-extension).
Using that stub-implementation, we can check Python modules for
validity as part of the test-suite.

The stub-implementation is needed, because otherwise every
Python module already fails at `import libcalamares`.

- stub-implement the API that is actually used by the Python modules
- in globalstorage, be slightly smart about what keys are being
  requested (so that e.g. all the modules that handle partitions
  information get an empty list and can manipulate that, instead of
  erroring out when they get a string)

- drop the unused "NAME" option for calamares_add_test
- while here reformat the module with the CMake style tool

- call it yamlcpp::yamlcpp

This is source-incompatible if targets link explicitly to yamlcpp

- Modules and plugins don't need to mention libcalamares themselves
  for linking -- we can do that automatically. Use the IMPORTED names
  so that it works in Calamares main repo and external repositories.
- Complain about unknown module types.

- merge the (not-installed) date-stamp and git-version
  files into ExtendedVersion, turn things into functions
- drop support for CVS (wut?)
- don't mention the branch, in git-versioning, because the
  hash is enough to find whatever
- don't need external program to find date, use `string(TIMESTAMP...)`

The check for skipping a subdirectory was applied to Python subdirs,
not to C++ subdirs. This meant that a skipped module would notice
only in calamares_add_plugin() that it should be skipped. The **rest**
of the CMakeLists.txt in the to-be-skipped modules' subdirectory
was not skipped, and so a test might be added for a module that
was skipped. Depending on how the test consumes the code/module
under test, that might fail to link.

Example module is *initramfs*. Reported by yonggan.

The skip-checking is now in the functions for adding plugins and
subdirectories, so that third-party building should get it
as well, for free. Since AddModuleSubdirectory and AddPlugin
use the newly split-out module, handling SKIP_MODULES and USE_*
consistently across module repositories is now easier.

While here, make accumulating-the-skipped-modules explicit.

There are two ways to skip building a module:
 - SKIP_MODULES (individually listed)
 - USE_* (pick one from a collection)

Move the handling for those ways to a separate function, so that it
can be re-used in the calamares-extensions module too, or other
external module repositories.