Automate artefact collection; build for all VS & clang versions

[h-vetinari]

So far, I've just been updating this recipe from the clang side, but I realize now that it's still depending on VS2017, and hasn't yet switched to the new VS2019 default.

But I realised that to be fully usable, this recipe needs to be built for all our available VS versions (as well as all our live clang versions), but that becomes very unwieldy and tiresome with all the hardcoded components/urls.

So I automated this and then expanded the build matrix. I also added myself to maintainers now.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• It looks like the 'winsdk' output doesn't have any tests.
• It looks like the 'msvc-headers-libs' output doesn't have any tests.

[h-vetinari]

(side note - wouldn't we want to build this for VS2019/VS2022 in parallel, like on the vc-feedstock? Or maybe even in the vc-feedstock, if we need to pin so hard to vc- resp. ucrt- versions?)

I'm thinking we should keep this here but perhaps build for the 2x2 matrix of supported (= two latest) VS resp. clang versions?

[h-vetinari]

@xhochy @isuruf
After much trial and error, I managed to automate the artefact collection here and generalize it to all VS-versions. The commits are cleaned up to be reviewable individually, though the "meat" of the matter is 10a7739.

I've tried to document my understanding of where the various versions come from, and I'd very much appreciate your review on this, as well as the automation of course (though the fact that it works should hopefully speak for itself). Importantly, I'm still inserting hard-coded links into the activation scripts (at installation time), so in principle they run exactly as before.

As far as I understand it, for full functionality we actually need the whole matrix of VS-versions times clang-versions that we have live in conda-forge; I've built this up incrementally: first automate only VS2017, then expand the VS-versions in CBC, then expand the clang matrix as well. You can see that the CI for all these stages is passing -- obviously we have a choice to reduce the matrix as desired.

PTAL

[h-vetinari]

After I had scripted all the automation, I ended up not using the component name explicitly in the activation script. I still think it's a value add to keep it, as that makes the activation script way more self-explanatory with the component names in COMPONENT_URLS, than if it were just a list of obfuscated URLs.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• The top level meta keys are in an unexpected order. Expecting ['package', 'source', 'build', 'outputs', 'about', 'extra'].

For recipe:

• It looks like the 'winsdk' output doesn't have any tests.
• It looks like the 'msvc-headers-libs' output doesn't have any tests.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• It looks like the 'winsdk' output doesn't have any tests.
• It looks like the 'msvc-headers-libs' output doesn't have any tests.

[isuruf]

Thanks