[GITHUB] Remove VS 2015 build from the CI

[Extravert-ir]

Let's establish a set of rules regarding compiler support in ReactOS to avoid holywars in future.

Proposed rules

• We officially support no more than two versions of each compiler.
• The term "officially supported" means there is a job on one of our CI systems (either GitHub Actions or BuildBot) checking both Debug and Release builds for this compiler for supported platforms (currently it is i386 and amd64). Every developer has to check changes against those compilers and/or fix breakages ASAP if they happen.
• Two versions usually mean having one "stable" version which is not changed often and one "latest" version. For example, VS 2017 and VS 2019 (or that will likely be VS 2022 soon) or RosBE-provided GCC 8.4.0 and the current latest release (GCC 11.1.0).
• "stable" compiler should be upgraded once in 2-3 years, or by a demand (for example, when it can't support our code anymore without too many hacks)
• Contributors can maintain support for other compilers and toolchains, but the topic of merging such changes should be treated carefully. First of all, it shouldn't require too many changes in our code base, especially for 3rd party modules.

So according to this set of rules, I suggest to leave these compilers as "officially supported":

• GCC 8.4.0 for RosBE (aka "gcc-stable")
• MSVC/VS 2019 (aka "msvc-latest")
• MSVC/VS 2017 (aka "msvc-stable")
• LLVM/Clang 12 (with MSVC and GNU-like APIs) (aka "clang-latest")

Clang does not have a "stable" version yet, as the work about its support is still in progress.

Reasoning

• Supporting each compiler requires an extra effort from every developer contributing to the project. Considering the size of our team, I think we may spend that time on something more useful. 4 versions is already a lot.
• The more a compiler gets old, the more work is required to update the codebase for a newer version. Remember our GCC 4.7.2 -> 8.4.0 transition, it took about 1.5 years in total to make it stable.
• Old compilers don't support newer language features and static analysis hints. This is especially relevant considering our plan to incorporate libcxx (LLVM's C++ standard library) into our project.
• Supporting two versions of a compiler is motivated by a fact that the majority of developers prefer using newer tooling, but that may lead to breakages from the compiler side (I'm looking at you, MSVC). In such a case, it is always better to have a more stable base to verify that the breakage is really caused by a compiler.

Additions and remarks are welcome.