Add cross-architecture continuous integrations under QEMU

[s1amese2003]

defs.h implements spin_loop_pause() and CACHE_LINE_SIZE for ppc64, s390x, riscv and
loongarch, but the continuous integrations build and run the tests on x86_64 and arm64
only, so those four branches are never compiled.

This adds one job per architecture. The job runs in a Debian container because Debian
serves all four architectures from a single archive and packages Boost.Test for each of
them, so enabling one is dpkg --add-architecture alone. The cross-toolchains build the
unit-tests and the example, and QEMU user-mode emulation runs them. Nothing is compiled
under emulation, so the whole matrix finishes in about eighty seconds.

One trade-off worth stating plainly: debian:testing is a rolling target, so unrelated
upstream churn can turn this job red. Ubuntu cannot replace it — no Ubuntu release has a
loong64 port, so there is no libboost-test-dev:loong64 to link tests.cc against. I
also have an Ubuntu-based variant that covers ppc64el, riscv64 and s390x with the
unit-tests and loong64 with the example only; happy to switch to it if you would rather
have LTS inputs.

Verification

Green on a fork: https://github.com/s1amese2003/atomic_queue/actions/runs/32273844744

Architecture	Compiler	Binary	Unit-tests
ppc64el	powerpc64le-linux-gnu-g++ 15.3.0	ELF 64-bit LSB, 64-bit PowerPC, OpenPOWER ELF V2 ABI	27/27, 83090 assertions
riscv64	riscv64-linux-gnu-g++ 15.3.0	ELF 64-bit LSB, UCB RISC-V, RVC, double-float ABI	27/27, 33938 assertions
s390x	s390x-linux-gnu-g++ 15.3.0	ELF 64-bit MSB, IBM S/390	27/27, 279698 assertions
loong64	loongarch64-linux-gnu-g++ 16.1.0	ELF 64-bit LSB, LoongArch	27/27, 33938 assertions

QEMU 11.0.3 throughout. The same four builds were also run locally in a Debian forky
container and produced identical assertion counts.

[s1amese2003]

A note on loong64, since this workflow only builds and runs the example there.

Full unit-tests on loong64 are achievable, just not on Ubuntu: no Ubuntu release has a
loong64 port, so there is no libboost-test-dev:loong64 to link tests.cc against.
Debian does package it — libboost-test-dev 1.90.0.2 covers loong64 in testing — so
running that job in a Debian container would give loong64 the same coverage as the other
three architectures.

I left it out because it would tie this workflow to a rolling release. While checking,
qemu-user-static had already been dropped from Debian testing as a real package (it is
virtual there now, with qemu-user taking over), which is exactly the kind of unrelated
churn that would surface here as a red CI.

Happy to switch the loong64 job to a Debian container if you would rather have the coverage.

[s1amese2003]

Correction to my note above: loong64 does not have to be limited to the example.

I moved the workflow into a Debian container, where libboost-test-dev:loong64 is
available, and loong64 now runs the full unit-tests like the other three architectures.
The pull request is updated. The sources.list rewriting the Ubuntu variant needed is gone
as well, and the matrix is uniform across all four architectures.

The trade-off moved rather than disappeared: this ties the job to debian:testing, a
rolling target. The Ubuntu variant is still available if you prefer LTS inputs — it covers
ppc64el, riscv64 and s390x with the unit-tests and loong64 with the example only.

[max0x7ba]

Thank you for your wonderful contribution of the advanced cross-platform CI, Li.

Your method of invoking the cross-compiler directly is a refreshing and elegant solution, in my opinion.

If you could address my comment, I would be happy to merge.

[max0x7ba]

Add -Wno-unused-variable to silence compiler warnings to both commands, please.