ci: Add AppVeyor testing support for C++20 and VS2022

[rleigh-codelibre]

• Add VS 2022 to test matrix
• Only build for C++20 with VS 2022
• Reorder build with newest variants first, so they get built first.
• Build VS2022 and VS2019 with Ninja; build time is 2.5 minutes per variant which is a good reduction from the previous 15 minutes per variant.

[rleigh-codelibre]

I didn't see an official support policy in the README regarding the support policy for older compilers, but given the size of the test matrix, it might be worth considering trimming down the number of variants being tested, which might include dropping some of the older Visual Studio compilers, maybe making C++14 the minimum baseline at this point?

[rleigh-codelibre]

The slowness of the AppVeyor CI meant I tested this on my own fork to get it working: https://ci.appveyor.com/project/rleigh-codelibre/glm/builds/44819373 is the passing build. Once the g-truc branch catches up, you should get the same green state. In the interim, this shows the improved build times for VS2022 and VS2019 due to the use of Ninja.

[christophe-lunarg]

"
Build VS2022 and VS2019 with Ninja; build time is 2.5 minutes per variant which is a good reduction from the previous 15 minutes per variant.
"

I agree this is great but I am a little concerned that I won't be able to maintain this Ninja code path. This said, I guess if it breaks, I could just remove it easily.

[rleigh-codelibre]

Just for reference, the main change is the bit to run vcvarsall.bat to get a working environment with the toolchain on the PATH. That's what the Invoke-VcVars bit is all about. See this search for examples of how to do it. What I've added here is adapted from this, and also from what I'm using in my own projects hosted on GitLab. Once that's set up, it's then just a regular "invoke CMake and run the build and tests" workflow as before.

The only other change is to switch the generator to Ninja for newer Visual Studio versions. This is just a change to the generator name, and also to how the build is invoked (the earlier generators are using non-portable generator-specific options which we drop to invoke portably).

It's possible you might encounter issues in the future--I can't prevent that--but what's been added here should be just as maintainable as what was already present.

[christophe-lunarg]

These changes were resolved by #1167 and the introduction of Github Actions C.I. for everything