Port main CI from Azure Pipelines to GitHub Actions

[kinke]

No description provided.

[kinke]

Okay, looks like this (AFAICT, undocumented) approach (from https://stackoverflow.com/a/70516118) would work to replace Azure Pipelines by GH Actions in a pretty smooth way, keeping separate 'includable' YAML files for a bunch of grouped steps. In the UI, such 'action' (sub)steps aren't expanded into the including job, but are nested in the action's step, and manually specified names for these nested steps aren't displayed unfortunately. Edit: Oh, and the action steps are apparently not collapsible separately either, so you can only collapse the whole action or display it all. Pretty bad for some test action covering LDC unittests, lit-tests, dmd-testsuite and defaultlib tests, we'd probably have to grep for the error again...

[kinke]

Getting there. Some observations wrt. GitHub Actions vs. Azure Pipelines:

• Nested steps in composite actions:
  • aren't inlined into the job, but nested in the action step
  • don't get their name displayed, but the first line of the command (annoying, hopefully changed someday)
  • aren't collapsible (annoying)
  • aren't displayed at all if skipped by if condition
  • can have explicit inputs, allowing to significantly reduce the usage of env vars
  • can show their extra env variables (by expanding their Run header line)
  • have their per-output-line timestamps collected, which can be displayed in the GUI (edit: oh, available for Azure too - with sub-second granularity even)
• Integration is obviously much better - less clicks to get to a CI log, much simpler setup/administration (e.g., no need for a Microsoft account, and no need to set up a token for GitHub release artifacts upload). It's so smooth that the test runs unexpectedly created a CI release in my personal fork (the workflow runs automatically/accidentally on my fork too…). ;) - So forks (on GitHub) should get Continuous Deployment basically for free.
• Being able to use 'foreign' GH Actions is nice and opens up new possibilities. Installing the latest LDC version as host compiler, installing ninja system-wide, but also more advanced stuff like fetching existing GitHub release artifacts (e.g., the Travis and Cirrus CI artifacts), so that the sha256sums.txt file contains those hashes too (as long as those 'foreign' jobs are already completed), and removing all existing artifacts (from the CI release) before uploading the new ones - so that I don't have to periodically clean up those CI release artifacts manually anymore.

Otherwise, it seems to be mostly the same thing, with some YAML and GUI differences on top of the same (?) agents+image infrastructure, incl. their general slowness (2 (Linux/Windows) / 3 (macOS) CPU cores only) and sporadic failures.

While going over the stuff, I've restructured things a bit to fit the new constraints; e.g., Windows is less exotic now and handled in the OS-generic actions. It's also mostly using bash now too, which also fixes previously missing || exit /b suffices for all batch file commands etc.

[kinke]

Oh, seems like GH Actions doubled the number of concurrent CI jobs to 20 for the Free plan (https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits). I was thinking about moving the supported-LLVM-versions jobs to Azure Pipelines, but that seems superfluous now...