Overhaul cmake build

This MR overhauls the cmake build system to fetch, compile and link all dependencies of the game statically, producing a single executable not dependent on anything other than dynamic libraries guaranteed to be on the system (stuff like user32.dll on Windows).

The intent is to completely replace the existing Makefile build system and make CMake the build system used for the game. This nets a few benefits:

1. The process for building the game is as simple as obtaining the source from git, installing msys2+mingw32, installing cmake in msys, and then running cmake .. && cmake --build .. No finagling of dependencies, no worrying about stdc++ compatibility, everything is guaranteed to be built for the toolchain you have installed, and the output is immediately distributable as-is.
2. CMake can generate build scripts for whatever system is most convenient. I have had promising results using Ninja on Windows, which is considerably shorter than current Makefile builds.
3. There is a single executable including everything. This is important in particular for macOS codesigning and notarization, because all included .dylibs must be notarized in addition to the binary.
4. We have more control over the enabled features of dependencies and the possible configurations of DLLs used in the field (that is to say, there is a single configuration, plus SDL2's ability to replace its functions at runtime).

Observations with the in-progress work:

1. The compiled .exe is smaller than the total size of 2.1.10 srb2win.exe + its DLL dependencies. This is likely because the linker is omitting symbols from dependencies not used by the game.
2. Initial CMake configuration is lengthy, but reconfigurations after are short.
3. The method used to make custom build of libpng could be extended to anything, though it is time-consuming and error-prone to setup.

Todo:

• Build libopenmpt internally
  • Hugely painful. This library really was not made to be consumed easily in a static-only context.
• Build Game Music Emu internally
  • Also potentially painful.
• Re-add a build path for linking available system libraries dynamically.
  • This is desirable for Linux targets, where it is more practical for operating system libraries to be updated by their package manager to fix security issues.
• Enable C++17 compilation and linkage Turning off for now, will do a more comprehensive integration of C++17 build support later
• Statically link standard libraries on mingw
• Optional SRB2_CONFIG_SHARED_INTERNAL_LIBRARIES flag -- this will still build the dependencies, but will link them dynamically. Considerably shortens srb2win's link time during development!