HMCL-dev
为HMCLauncher添加CMake以及gcc支持和其相应的Github Actions
支持多个工具链需要维护更多的编译脚本和更多测试。测试 HMCLauncher 本身就很麻烦，支持 MinGW 后每次更新后工作量都会更大，而且使用 MinGW 编译没有实际价值，所以我反对此 PR。
大部分开发者即使有 Windows 环境，也只有 cmake 和 gcc，不会专门去下一个 msbuild。并且，msbuild 非常重，专门为开发 HMCLauncher 下载一份极其痛苦。
我建议将 CMake 编译作为可选项，仅提供 CMake 但不提供 GitHub Action 做到能用即可。用于构建 HMCL 的版本仍然通过 msbuild 构建
VS 环境对于 Windows 上的 C++ 开发者几乎是必备的，Win32 程序部署基本都是用 MSVC，Windows C++ 开发者很少有用 MinGW 而不去装 MSVC 工具链的。我希望各位所用的开发环境还是尽可能和实际部署环境看齐。
HMCL 开发者通常技术栈都由 Java 向外辐射，涉及到 C++ 的部分也就只是 JNI 了…… 因此大多装 MinGW。况且，msbuild 极其重，专门为开发 HMCLauncher 去下这么大个东西着实痛苦
支持多个工具链需要维护更多的编译脚本和更多测试。测试 HMCLauncher 本身就很麻烦，支持 MinGW 后每次更新后工作量都会更大，而且使用 MinGW 编译没有实际价值，所以我反对此 PR。
我最主要的想法还是HMCL作为开源软件，HMCLauncher也最好有使用开源工具链的编译解决方案；至于兼容性问题，理论上使用标准C++的情况下MSVC和g++/clang++的区别也并没有那么严重。本身HMCLauncher的代码的绝大部分也可以不经修改在gcc+mingw的环境下编译，真正对源码的修改只有main.cpp中涉及_declspec(dllexport)的部分需替换成gcc/clang中的相应形式。 这个pr的目的也只是提供使用其他编译器来编译HMCLuncher的可能性，我们可以声明HMCL的开发团队仅仅支持MSVC编译的HMCLauncher，对CMake以及其他编译器的支持属于实验性支持，不给予任何担保并且不保证修复bug。同时官方发布的HMCL将仍然使用MSVC作为HMCLauncher的编译器，理论上这也不会对发布流程有任何影响