Removed:
* Two linux jobs - now only two combinations of the gcc/clang + scons/cmake matrix are run.
* Two macOS jobs - the Release configuration is now only run on ARM, and the Debug configuration is only run on Intel.
Also pinned vcpkg to a particular commit so it doesn't ignore the cache when new versions of dependencies come out. This does mean though that when dependencies or dependency versions change that the vcpkg commit and the cache ID will need to be manually updated. And while it's *probably* safe to have stable and master share the same vcpkg cache, this may become problematic if their dependencies and/or versions become incompatible.
Due to an upstream change in vcpkg that breaks the simple integration previously available with `vcpkg integrate install`, building using that setup method is no longer possible. In order to work correctly, cmake must instead be used to generate the VS project files, since that is able to integrate with vcpkg, since vcpkg also uses cmake to build all the library dependencies.
An additional benefit of this is that it will no longer be necessary to separately update the VS project files since it will read the same source_lists files as cmake (on linux) and scons do.
This also enables running the WML unit tests on Windows with this in order to confirm that a valid wesnoth.exe is in fact being generated as well as fixes building the boost unit tests.
The warning level for both release and debug builds are now at level three, the remaining warnings have been fixed, and therefore strict builds have been enabled - any warning will now cause the build to fail, just like for the linux jobs.
Known issues:
* The boost unit tests don't actually run successfully - they fail on CI at least with an exit code on 201 - however I don't know if this is a real problem or just a problem with running headless on CI.
* The debug build doesn't quite work since the executables are built against the non-debug dlls but cmake copies over the debug dlls into the output directory. For now this can be worked around by copying the release dlls into the debug directory.
* The instructions in INSTALL.md are not very good since I don't use Windows and thus can't write anything more detailed. Ideally someone who uses Windows can add more detailed step by step instructions at some point.
Fixes#5741
Quick workaround for #5741, the Windows builds weren't finding Pango's header
files when used with vcpkg version 546813ae7b9e2873dd3d38e78b27ac5582feae10
([glib up to gtk] update and make it work with meson).
Hopefully we can revert this workaround soon.
