Transition 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.

Regarding outstanding PRs: any other pull requests or alternate branches in progress that require modification of the VS project files will need corresponding modifications made to the CMake project files in order to work. That is to say, if you added or deleted a source code file in some custom branch of NASSP, you'll need to add or delete that file in the appropriate vessel's CMakeLists.txt in order to incorporate those changes into this new CMake-ified setup. I'd personally recommend getting familiar with the basic workflow of building NASSP like this first, and then move up to porting your PRs or branches to this new system. And please let me know (preferably on Discord) what challenges you face or questions you have.

Until we progress towards actually merging this, I will be rebasing and force-pushing this branch periodically to bring it up-to-date with upstream changes in a way that doesn't cause merge commits, for cleanliness' sake. BE AWARE that if you make a fork of this branch or clone it, the remote branch can (and will) spontaneously disconnect from your local change history, even if you don't make any personal changes. This will probably break things on your end and require you to reset the branch.

To do this, I recommend the following steps (this will discard any custom changes you've made):

git reset --hard HEAD~50 (Resets the changes back by 50 commits, to get us back to a state before any CMake-related changes)

git pull (Pulls the changes from the remote branch, which will have the latest upstream changes, with the CMake-related commits always at the very top of the list)

Please DO test this branch out! But until we know this is actually in a good place to be merged, please DON'T do any work with it that you aren't willing to potentially re-do.

[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.