Try 1 fast 2CPU and 3 slow 1CPU aarch64 runners

[mathbunnyru]

Describe your changes

Depends on: #2066
Our time measurings will change after using actions/{download,upload}-artifact v4.
After we merge the mentioned PR, it might make sense to reconsider the speed of self-hosted runners we're using.

Issue ticket if applicable

Checklist (especially for first-time contributors)

• I have performed a self-review of my code
• If it is a core feature, I have added thorough tests
• I will try not to use force-push to make the review process easier for reviewers
• I have updated the documentation for significant changes

[mathbunnyru]

The fresh run: https://github.com/jupyter/docker-stacks/actions/runs/7513154764

The best speed we can achieve (for the building phase, not including push + merge tags, because there is nothing to optimize there, to be honest) is 1min21s+2min52s+3min39s+6min6s+6min3s+7min32s, which is 27min33s.
https://github.com/jupyter/docker-stacks/actions/runs/7513154764

The time comes from x86_64 runners, there are an unlimited number of them (for our purposes the number is practically unlimited), and they are 4CPU machines.
Most of the time difference comes from running tests (they do run in parallel).

So, it makes sense to speed up our aarch64 runners.

The coolest thing would be to implement autoscaling though: https://medium.com/google-cloud/autoscaling-runners-on-google-cloud-f285ed8d85de
This way we would be able to run 4CPU machines easily, with zero idle VMs. And it would cost many times less.
I welcome such a change, but I still hope GitHub will provide aarch64 Linux runners one day.

[mathbunnyru]

aarch64 build phase took approximately 40 minutes, that's nice. Really close to the optimal build time.

Total CI time in configuration 3x1CPU+1x2CPU 43m 42s, which is also significantly better than the configuration 4x1CPU 1h 1m 38s.

(All comparisons are made already with v4 download/upload artifact actions, of course).