[ci] Upstream ci-templates: add rpi* build templates so the buildbot can ship per-SoC Raspberry Pi cores

[JoeMatt]

Follow-up to #560 / PR #567. Needs a discussion with the libretro devs before any PR is opened — filing this so it isn't lost.

What's missing

libretro-infrastructure/ci-templates has no rpi* template. Enumerated from the GitLab API: 65 templates, and the only ARM-Linux one is linux-aarch64.yml.

dingux-arm32.yml  ios-arm64.yml  linux-aarch64.yml
osx-arm64.yml     osx-cmake-arm64.yml  tvos-arm64.yml

So the libretro buildbot cannot build per-chipset Raspberry Pi cores for this repo, no matter what our .gitlab-ci.yml says. That half is genuinely upstream, not ours to merge.

What we already have (PR #567)

The Makefile side is done and verified — per-SoC tuning for every Pi target:

platform	SoC	core	blitter	flags on top of -O3
rpi0 rpi1	BCM2835	ARM1176JZF-S (ARMv6)	scalar	-marm -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
rpi2	BCM2836	Cortex-A7	neon	-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
rpi3 / rpi3_64	BCM2837	Cortex-A53	neon	-mcpu=cortex-a53 (+32-bit fp flags)
rpi4 / rpi4_64	BCM2711	Cortex-A72	neon	-mcpu=cortex-a72 (+32-bit fp flags)
rpi5 / rpi5_64	BCM2712	Cortex-A76	neon	-mcpu=cortex-a76 (+32-bit fp flags)

GitHub nightly + release artifacts already ship all eight distinct targets via release.yml's matrix, cross-compiled on x86_64. This ticket is only about the GitLab buildbot.

What an upstream template would need

Nothing exotic — linux-aarch64.yml is the model. The differences:

1. Cross-compile, not native. linux-aarch64.yml runs on a native aarch64 runner with plain gcc. Pi templates should cross-compile on x86_64: -mcpu names a core to generate code for, it does not require running on one, so no Pi hardware is needed in the fleet.
   • armhf rows: gcc-arm-linux-gnueabihf
   • arm64 rows: gcc-aarch64-linux-gnu
2. Pass platform=rpiN and the matching CC/CXX. All the tuning lives in the core's Makefile — a template must not duplicate -mcpu, or the two will drift.
3. Use the cross objcopy/strip. Ubuntu's binutils is single-target, so the host x86_64 objcopy cannot read an ARM ELF. STRIP_CORE_LIB=1 in linux-aarch64.yml would need a prefixed STRIP.
4. Eight rows (rpi1, rpi2, rpi3, rpi3_64, rpi4, rpi4_64, rpi5, rpi5_64). rpi0 is redundant with rpi1 — same BCM2835 part, identical resolved flags.

Questions for the devs

• Do they want per-SoC Pi cores at all, or is the position that one generic linux-aarch64 build plus one armhf build is enough? That is the real decision; everything else follows from it.
• If yes: one parameterised rpi.yml taking the SoC as a variable, or eight small files matching the existing one-file-per-target convention?
• Is there an existing naming convention for Pi artifacts on the buildbot that we should match rather than invent?
• Do any other cores already carry per-SoC Pi tuning that we should be consistent with?

Verified locally (so the template author has ground truth)

Cross-built the real core in arm-linux-gnueabihf / aarch64-linux-gnu containers:

• rpi1, rpi2, rpi4 → ELF 32-bit LSB shared object, ARM, EABI5
• rpi4_64, rpi5_64 → ELF 64-bit LSB shared object, ARM aarch64
• cross objcopy --strip-debug --strip-unneeded succeeded on all five

Two traps a template author will otherwise hit:

• -mfpu/-mfloat-abi are 32-bit-ARM only. aarch64 gcc hard-errors: unrecognized command-line option '-mfpu=neon-fp-armv8'.
• rpi0/rpi1 need -marm. Debian's armhf toolchain is --with-arch=armv7-a+fp and defaults to Thumb; ARMv6 has only Thumb-1 and GCC cannot pair it with hard-float (sorry, unimplemented: Thumb-1 'hard-float' VFP ABI). Native Pi 1 compilers default to ARM mode, so this bites cross-builds only. Our Makefile already handles it.

Not blocking anything

Users get optimized Pi cores from the GitHub nightly/release today. This only affects what the libretro buildbot publishes.