CI: Add a cross-build scenario

[jimklimov]

As highlighted in #1289 and 567ab95 discussion, the fightwarn effort (#823) backfired a bit by using configure-time attempts to compile AND run some code.

While this helps on systems that can actually run built code (natively or with qemu interceptors), the tests involved fail for "common" cross-build setups (where compilers can generate correct bytes for the binaries, but same system can not run them).

When/if the original issue with build recipes is addressed, un-blocking the cross-builds per se, we would need some CI job (current NUT CI farm? GitHub Actions?) to run some cross-builds regularly to avoid regressions in this area.

[jimklimov]

Maybe worth doing this in tandem with #1333 to cross-build those dependencies we would cross-build NUT against.

Alternatively, explore Debian/Ubuntu(/others?) support for additional architectures with libsomething:arch package names.

Note PR #1334 touched a bit in this area, adding CI_CROSSBUILD_HOST and CI_CROSSBUILD_TARGET (suffices to specify one if they are equal), to reproduce builds similar to what was described in issue #1289.

The autoconf based builds seem to play well with gcc (with respective variant of that toolkit installed), but not with clang which does not seem to receive correct parameters for the single installation to build for any target as per https://mcilloni.ovh/2021/02/09/cxx-cross-clang/ (notably, no separate sysroot is even asked for or I did not quickly find that).

[jimklimov]

As a data point, work done in Windows branch for cross-building NUT in Linux+mingw (on environments without WINE so can't even run NUT binaries there) may be counted as a working cross-build, regularly running in NUT CI farm as the Windows effort is iterated.

It is not tightly integrated with ci_build.sh yet, however, so not all ideas from above are addressed.

Also, regularly building for more target systems (e.g. Raspbian? OpenWRT?) would still be practically relevant, to document and script how this is done reliably and reproducibly.

[jimklimov]

In #1490 I was made aware of https://github.com/mstorsjo/llvm-mingw which delivers clang mingw setups both for cross-builds (executed from Linux to make binaries for Windows) and natively. Installable as tarballs and usable as Docker images.

[jimklimov]

Recent work on MacOS builds with Homebrew packages uncovered that it is also a sort of cross-build, at least as far as autotools warnings were concerned (a different set of headers and libs, although the resulting binaries are intended to run on the same platform/OS/CPU as the build host).