Switch to CMake and fix compilation with VS2022

[mrexodia]

This has been on my personal roadmap for a while, but wanted to add an issue to track it.

• Add a CMakeLists.txt in parallel to x64dbg.sln
• Support VS2022:
  • Fix all warnings
  • Fix Visual Studio analyzer results
• Add TitanEngine/GleeBug as submodules
• Add an option to automatically download a supported Qt5 LTS version (VS2019)
• Integrate clang-tidy
• Clean up the project root
• Support “offline” builds (ready-to-compile source package)
• Create an external plugin for Scylla (latest fork)
• Upgrade dbghelp.dll and msdia140.dll to the latest version
• Restore delayed imports
• Restore signing functionality for latest MSVCRT
• Remove TitanEngine/DeviceNameResolver and other internal libraries from the pluginsdk
• Update compilation instructions in the wiki
• Update the QtPlugin template and PluginTemplate
• Delete the old .vcxproj and x64dbg.pro files
• Fix the relative submodule path when forked (url = ../../x64dbg/deps)
• Make sure the exe project is the default startup project in the generated solution
• Update CONTRIBUTING.md to match the new workflow
• Remove licenses from docs folder and pull them dynamically during the build to avoid multiple licenses being detected for the repository

[torusrxxx]

Next milestone of adding AVX-512 support as part of #3136, will require modification to debug engines.

[mrexodia]

Do we actually need to support AVX-512? They removed it from the new CPUs and my CPU from 2020 doesn't even have support for it 😅

[torusrxxx]

It's just the incompetency of Intel. AMD has no problem supporting AVX-512. I will test it on a computer with AVX-512 myself.

[mrfearless]

I was looking at Steam Hardware Survey just yesterday when Steam prompted me to take my info, and I had a look at the last section with the cpu features. For myself I was curious to see the uptake of SSE etc, but noticed the low usage of AVX512 currently.

Of course the sample size is limited to gamers, but still interesting to see what is current, and what may be more prevalent in future.

https://store.steampowered.com/hwsurvey/

[mrexodia]

Yeah the prevalence might be low, but supporting it transparently shouldn’t be that much of a burden. So why not? 🤷‍♂️

[mrexodia]

I merged the CMake project as an initial step, to hopefully at least make it easier for new people to contribute. It will likely be unavoidable to break the Qt GUI plugins when upgrading the toolchains (name mangling is different), so I think we can upgrade to the latest Qt that has XP compatibility.

We would then start informing users about full XP deprecation (perhaps we can provide instructions to use something like https://github.com/Chuyu-Team/YY-Thunks or https://github.com/Skulltrail192/One-Core-Api-Source). XP has been out of support since 2014, which is more than 10 years, but I feel it keeps new contributors out and the maintenance burden is constant.