Switch AppVeyor to a sparse build matrix

[zeux]

AppVeyor is dramatically slower than GHA, and after recent VS2026 addition it is approaching 30 minutes of build time. It tests multiple configurations per VS version, many VS versions, and the builds are all sequential due to free tier limitations.

This is becoming unsustainable and the cross-configuration/version build problems are quite rare; additionally we do already test all of this for the latest VS version on GHA.

So it is time to dramatically reorganize the build configuration by making the matrix sparse: for each VS version we now only test one manual cl run with an interleaving of architecture and configuration selection, so that we hit every combination of arch-defines, and the combinations are somewhat creatively chosen to still exercise commonly seen configurations.

We still build CMake in addition to that, and of course all recent VS versions (2017+) build the NuGet package too; so in practice we get more than one pugixml.cpp build per agent, but just one build with all tests.

[zeux]

This looks like it cuts something like 10 minutes from the full build time in stable state although AppVeyor seems to be experiencing problems today so the builds are longer by default... as a result it's hard to quantify the exact speedup. Not as good as what I was hoping for, but we can't really improve any further unless we drop entire configurations; it looks like a compounding effect of NuGet package build (4 pugixml.cpp builds per VS version), CMake build (1 pugixml.cpp build per VS version), and full test build & run per VS version.

VS 2017 is in support until April 2027 so we can't drop its NuGet build for some time, so at best we could entirely drop testing for pre-2017 versions, but this actually flagged some build warnings in recent PRs so that doesn't feel that good either, and these versions are significantly faster to build so that entire job run is now approximately on par with later VS versions despite also building two Cygwin coverage builds (but no NuGet).

This is probably as good as it gets for now, unfortunately. Definitely the highest leverage next step is to drop entire images because even just the image startup time is quite significant. Looks like VS2015 is available in the VS2017 image so we could merge these two and drop all pre-2015 versions perhaps...

[zeux]

Before this PR:

After this PR:

It takes ~30 seconds per job of image startup overhead so moving VS2015 tests into VS2017 image would probably save us about 3 minutes. Likely not worth losing additional compiler coverage for now, but maybe we can consider it in the future.