CI: GitHub Actions CI job restructuring

[rgommers]

Implements most of what is discussed in gh-24410, and documents what each job does. It removes some duplicate jobs, and adds a few notes and TODOs for where we miss coverage.

For the two files with a large number of jobs (linux.yml and linux_simd.yml) we run the same smoke_test which acts as a gate for the other jobs. That's an unavoidable duplication, but it takes only ~6 minutes so that should be fine. If there are only 2-3 jobs in a yml file, we don't run a smoke test. Overall, this will cut down on the number of jobs and make them easier to maintain.

[rgommers]

This is happy now. Should make it easier to iterate on things in parallel after this is merged. We basically have to get rid of uses: ./.github/actions from all these jobs, which is the part that's hitting the setup.py builds.

[charris]

Could get rid of the blank line at some point.

[charris]

Thanks Ralf.

[mattip]

Here are the current workflows on github actions and the time they take to run (after merging this PR)

Workflow	time	Runs on merge to main
BLAS tests (Linux)	9-14 min	no
CircleCI artifact redirector	10 sec	no
CodeQL	5-7 min	yes
Dependency Review	< 20s	no
Linux Qemu tests	20-25 min	no
Linux tests	19-30 min	yes
Pull Request Labeler	<20s	no
Run MyPy	6-14 min	no
Scorecards supply-chain security	1 min	runs only on merges
SIMD tests (Linux)	23-26 min	no
Test Address Sanitizer Build (Linux)	19 min	see PR #24208
Test Emscripten/Pyodide build	10-15 min	no
Test muslinux ×86 64	9-10 min	no
Test on Cygwin	34-50 min	no
Test with compiler sanitizers (Linux)	21-32 min	no
Wheel builder	20 min	mostly skipped, runs on a schedule
Windows tests	14-17 min	no

In addition we have the

• azure workflow that takes ~34-50 min
• the cirrus builds (two jobs: ~12 minutes on aarch64 linux and ~3 minutes on macos-arm64) and
• the circleCI workflow that takes ~23 min

[rgommers]

Thanks! That's a useful overview. Perhaps good to post it on gh-24410 too (more discoverable)?

I think we should first get rid of all the setup.py files, and then see where we're at before doing anything else. We can restructure jobs, triggers, etc. after that.