Treat GitHub Actions CI like travis/appveyor CI

[bernhardmgruber]

The problem with the current GitHub CI is that we do not know what instruction set the runners support. test.cmake has a detection mechanism for travis, but not for github actions, where it ran a simple CTest build (whatever that does, maybe testing what the host supports itself). On appveyor, a more complicated test setup is used, where CTest is invoked multiple times with different instruction sets, based on the environment variable subset. When the #278 was merged, the tests ran in a skylake CPU supporting all instruction sets. Current CI builds like #286 run on a broadwell CPU not supporting all instruction sets, which likely causes CTest to fail to enumerate the test suite.

[bernhardmgruber]

The question for me is, why were the Windows builds handled differently than the Linux ones? Most likely it was the build time, becaues VS takes 44min to build and run the test whereas clang takes 22min. Because we could just run all builds using the first branch.

[bernhardmgruber]

I think there could have been a change in CMake.
Appveyor runs with CMake 3.16.2 and GitHub actions with CMake 3.21.1. There is this recent issue with CMake: https://gitlab.kitware.com/cmake/cmake/-/issues/20283

Unfortunately, I cannot find a way to pass the -C inside test.cmake to ctest_test.

[bernhardmgruber]

I merged the Windows builds now into 1 CI job and let them use the same codepath as the Linux builds. That avoids multiple reconfigurations of ctest during 1 CI run.