Support riscv64, ppc64, ppc64le and loongarch64 targets

[talaria0101]

Add the four architectures end to end: the hand-written gl-fwd
trampolines (riscv64 and loongarch64 classic tail-jump forms; ppc64
split by ABI, ELFv2 TOC with a global entry for ppc64le and the ELFv1
.opd descriptor hop for big-endian), the loader and triplet names in
runtime-select and cross-libc-dlopen, the cross builds in
scripts/build.sh and build-in-env.sh, and CI rows that build all four.

Measurements behind it:

• Before this change, compiling src/gl-fwd.c for any of the four hit
  the "needs a tail-jump trampoline" error on gcc-10 and gcc-14; after
  it, make gl-fwd-asm-check assembles all five cross halves and make
  gl-fwd-qemu-check runs them under qemu-user: one argument of every
  register class through a trampoline, verified inside the target, a
  second call through the patched slot, a double return value, and the
  absent stub's zero in both the integer and the float return register.
  On ppc64 that includes the real ld64.so.1 walking .opd descriptors.
• Every artefact builds and passes scripts/verify-artifacts.sh on each
  architecture, floor glibc 2.31 on the bullseye cross toolchains and
  2.36 on loongarch64, which only exists from glibc 2.36 and needs the
  trixie cross compiler (gcc-10 has no loongarch64; checked against the
  Debian archive indices). build.sh selects that image by itself.
• The export-count check in the Makefile and verify-artifacts.sh moved
  from nm to readelf: an nm built without PowerPC reads ELFv1 .opd
  functions as data, and the count refused a correct ppc64 build
  (measured 0 against 3470).
• runtime-select's GLIBC_ version parse no longer uses sscanf: with
  _GNU_SOURCE and gcc 13 or newer, glibc redirects it to
  __isoc23_sscanf, which first exists in glibc 2.38, and the artefact
  silently needed 2.38 (measured on the gcc-14 loongarch64 build; the
  replacement parses identically on every version string shape,
  including wrap-around). loongarch64 now tops out at GLIBC_2.36.
• ld64 added to the never-touch list: the ppc64 loaders ld64.so.1
  (ELFv1) and ld64.so.2 (ELFv2) do not start with ld-linux.

Unverified, and stated in docs/report/10: the four architectures have
run under qemu-user and never on silicon, no host Mesa has been behind
the shims on them, and the AppImage evidence suite has no demo assets
for them. run-evidence.sh could not run on the machine that produced
this change (no container runtime available); CI runs it.

---

Requested by Samueru via pi-discord.
Conversation: https://discord.com/channels/1313385177703256064/1545249294377033729
Transcript: https://talaria.qaidvoid.dev/?session=1i2d05e