Upgraded buildsystem

[W-Drew]

NifSkope currently uses qmake & hand-copied third-party dependencies (git submodule usage is only partial). This causes several challenges that would be alleviated by a modern buildsystem:

1. Building release locally does not get the build into a state that can be uploaded as-is to GitHub Releases, allowing for mistakes that can result in a bug that is present only in the uploaded release but not source control:

It's supposed to be edited with the source control, but it's easily forgotten. There's even been cases of edits in the xml that made it into a NifSkope release without ever being in the xml repository, though that's obviously not how it's supposed to happen.

Originally posted by @Candoran2 in #67 (comment)

2. External dependencies like nif.xml that are not proper third-party dependencies and get copied over by hand can result in miscellaneous edits getting in that are not part of the upstream third-party

3. Toolchain versions are unclear. The wiki shows things built using Qt 5.9 as does the Qt .pro file, but builds fail unless a later Qt version is used. dev8 appeared to be using Qt 5.13, while dev9 appears to be using Qt 5.15. The exact Visual Studio toolchain is also unclear given that the .pro file is unreliable. It says vs2017, though looks like it might be vs2019 at this point? A modern buildsystem allows us to bake in these specific toolchain versions so that there is no ambiguity. You can check out a prior commit too and know exactly what you need to build it.

4. qmake compatibility with other, non-Qt tooling is poor

This could all be rectified with a more modern buildsystem like cmake. cmake allows the automation of dependency fetching (supports any kind -- more than just git submodules), organizing builds in a way that can be immediately published as a release without any extra manual fixup, and unambiguous toolchain version specification that can throw user-friendly errors if the requirements are not met. Also, as opposed to qmake, cmake is an industry standard and widely supported across C++ tooling: Microsoft & Jetbrains both provide first-party cmake support for VS, VSCode, and CLion, many third-party libraries provide their own CMakeLists.txt should we need to take additional dependencies in the future, and cmake even supports Qt out of the box. Roblox Studio, for instance, is a massive Qt application, but it is built using cmake rather than Qt's tooling. cmake is also the standard buildsystem used for SKSE/FOSE/SFSE / CommonLib and their plugins. Building a cmake project just requires cloning the repo, opening it in the IDE, and clicking build -- all of the extra steps required now would automatically happen behind the scenes.

[W-Drew]

This is a large amount of work, but I am volunteering for it. Since a big change like this is a big departure from what we use today, using this Issue for consensus on whether to make the switch