This doesn't make all these modules actually work with Qt6 yet, but it
prevents them from unconditionally pulling in Qt5 in a Qt6 build.

This is useful in order to even be able to pass a CMake run to the
point one can port, test and debug the rest.

PKG_CONFIG_SYSROOT_DIR only applies to -I and -L flags, so pkg-config
does not prepend CMAKE_SYSROOT when cross-compiling unless you pass
--define-prefix explicitly. Therefore we have to  manually do prepend
it here when cross-compiling.
See https://gitlab.kitware.com/cmake/cmake/-/issues/16647#note_844761.

With this change I no longer get errors related to wayland.xml when
cross-compiling KWaylandServer.

When cross-compiling QT_INSTALL_BINS contains binaries for the target
system that can't be used during the build. Instead use QT_HOST_BINS
which contains the Qt build tools for the current system.

Plain freedesktop.org 302-redirects to www.freedesktop.org.

Also, fixes a warning during CMake generation step in plasma-desktop.
See https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/572

The proximate problem is that the Python Module generator cmake script
has started failing for people with Python 3.10, which a CMake backtrace
pointing into FindPythonModuleGeneration.cmake with an error of the form
"The max python version in PythonModuleGeneration must be updated."

At least one distro has addressed this by simply patching out modules
that happen to use this CMake module [1].

From what I can tell and the testing I've done, the cause is pretty
simple: The CMake script attempts to find the best Python 3 version by
starting from an impossible version and working backwards until it finds
a version that is installed.

As a sanity check, if the "impossible" version is actually present, it
aborts. But this appears to be just a sanity check, and not any sort of
guard against buggy version handling code later.

While the best fix is probably to start from a known *good* version and
move up until we stop finding better versions, there's problems here
(e.g. a user with 3.6 and 3.8 installed would fail to see 3.7 and so be
left with 3.6 as the "best" match), so I opted just to increase the max
version significantly, and improve the documentation as to what's
happening and whether it is safe to repeat the step again later.

[1]: https://bugs.gentoo.org/746866

GIT_SILENT