Transition development to Orbiter 2024 x64, change build system to CMake

[CaptainSwag101]

I believe that NASSP would gain significant benefits from transitioning our build system to use CMake. In a nutshell, CMake is a higher-level, more abstract system than something like the Visual Studio project files that we currently use to define our vessels, libraries, MFDs, etc. Rather than directly instructing a C++ compiler on how to build the code, it processes a set of instructions like a script, and generates an intermediary output file which is then used by a C++ compiler to build our code. (In theory, CMake can actually be used to generate VS project files, which is pretty cool.)

CMake has some very nice features for those familiar with it, but it will also let us keep our existing workflow relatively unchanged. Some particular benefits I see for NASSP are as follows:

• Having much less verbose, human-readable project files that can be edited like source code, and which will play nicer with git.
• The ability to use logic within our project files and introduce/remove in-code definitions directly from the build system, depending on user-defined settings or for particular build configurations. As an example, while we would eventually like to not require explicit code changes to enable J-Mission systems, CMake could (with some work) allow toggling J-Mission code and systems configs with a single check-box, while we figure out a more elegant and modular solution down the line.
• It gives our project files a "clean slate" free of the roughly 20 years of legacy leftovers and inscrutable per-project tweaks and adjustments. This also helps make them easier to understand as a side-effect.
• More progress towards an OS-agnostic future. While CMake is compatible with Visual Studio, and can even be used to generate VS project files if desired, moving away from direct reliance on Visual Studio will give us more flexibility going forward with what tools we use, and if Orbiter ever makes a full transition away from Windows-specific SDKs and libraries, this will make it easier for us to follow suit.
• Significantly less work is required to enable OpenOrbiter/Orbiter 2024 compatibility, with the added benefit of being able to keep VESIM functionality in all situations. OpenOrbiter/Orbiter Beta detection is now done automatically based on the presence of "lua.dll", which should only exist in OpenOrbiter/Orbiter 2024 installations because it's named differently in Orbiter Beta. No more separate branches and frustrating merge conflicts; now one branch can build for both versions of the simulator.

Since these changes would inherently allow for OpenOrbiter compatibility, this PR supersedes #793.

I have had several devs personally encourage these changes, and I am naturally an advocate for switching to CMake after seeing the workflow and practical improvements it offers us. As-is, the only changes needed to put this in a fully "ready for prime-time" state would be to delete the old VS project files, to ensure users don't get confused and use the wrong system. I have not done this yet, for the sake of making it easy to merge/rebase to upstream changes or for folks to experiment with migrating their outstanding pull requests if they so desire. These are foundational changes, and I want to give everybody plenty of time to figure out what this is all about, and to test and give me feedback on workflow, stability, and other issues that I can't discover by myself. I have only been using and learning about CMake for a year or two, and this is by far the most complex thing I've done with it. Nevertheless, I have been very encouraged by how simple it has been to re-organize a project as big and complex as NASSP into this new build system with relatively little work; I think it speaks to CMake's strengths that it can be done by even someone as relatively inexperienced as me.

[thewonderidiot]

Is there a reason why you're only passing one library to each target_link_libraries() call? You could instead do something like

target_link_libraries(${PROJECT_NAME} PRIVATE
    GLU32
    dxguid
    dinput8
    OpenGL32
    User32
    WinMM
    WS2_32
    Orbiter
    Orbitersdk
    PanelSDK
    XRSound
)

which would be less verbose and potentionally a bit more performant on the CMake side.

[CaptainSwag101]

Ahh, I didn't realize that was possible, thanks! Much more elegant.