Refactor CI to return better results faster

[bifurcation]

This PR replaces #398, which started out small and turned into kind of a disaster. This PR restructures the MLSpp CI. Before, we did a single Linux build first and then ran clang-tidy build on all three platforms:

With this PR, we immediately launch build + unit test jobs on all three platforms, with all three choices of crypto library. Clang-tidy is done only on Ubuntu (the most available platform, and unlike macOS, doesn't hang), and interop testing is only done once (also using Ubuntu).

Along the way, I made some smaller changes that make the YAML easier to read:

• Make CMAKE_TOOLCHAIN_FILE an environment variable
• Make OpenSSL 1.1 parallel to other crypto libraries
• Simplify out the vcpkg-dir variables
• Factor out build preparation steps into a composite action

The only change to code is a minor change to zeroization and its test in lib/bytes/. The Zeroization test in that file deliberately reads freed memory in an attempt to verify that memory is zeroized before being freed. This test was already disabled when ASAN was enabled (since its whole purpose is to detect UAF!), but we also disabled on Windows because it seemed to be causing problems. While I was researching Windows memory issues, I discovered the SecureZeroMemory() function, which seemed safer than the std::fill() call that was there before, so I added code to use that.

Nonetheless, Windows CI builds still seem to hang during the unit tests when they are built without SANITIZERS=ON, so that flag is always on in the CI builds, which slows them down a little.

My only real remaining question is whether we should continue to run the different crypto libraries matrix-style, or whether we should just run the three of them manually in one job. I find the 9 jobs a little aesthetically unpleasing, and caching might work a little better.

[birarda]

My only real remaining question is whether we should continue to run the different crypto libraries matrix-style, or whether we should just run the three of them manually in one job. I find the 9 jobs a little aesthetically unpleasing, and caching might work a little better.

I prefer the 9 jobs personally. Definitely a bit unwieldy in the UI to deal with more tasks, but I think it's nice to isolate since it makes clear at the top level what is failing or what is yet to be run. There might also be some parallelization benefits to having them separate? Not familiar enough with actions to know how that works.

[glhewett]

No show stoppers (so approved), but I have some comments.