Bundle qboot for x86-64

[jacob-carlborg]

Adds qboot.rom from QEMU's pc-bios to the qemu-system-x86_64 tarball, so a
guest can be booted on QEMU's microvm machine type: no boot loader, no PCI bus
and no ACPI, which is worth a few seconds of every job's startup.

-kernel reads like a way around the firmware and isn't one. QEMU stages the
kernel and publishes where it starts, but something running in the guest still
has to jump there, and on microvm that is qboot. qboot is also what leaves an
MP table behind, which is the only place a guest configured without ACPI can
read the machine's CPUs and interrupt routing from -- NetBSD 11's MICROVM
kernel, the first consumer, is configured exactly that way. Handed
bios-256k.bin instead, such a guest never starts and says nothing at all
about why.

It is prebuilt in QEMU's own pc-bios directory, so it is copied from the same
tree the binary is built from and cannot disagree with it. The qboot version
does matter: the smolBSD project carries its own copy specifically to work
around qboot smashing its stack in QEMU 9.0 and 9.1.

Measured

Booting NetBSD 11.0 x86-64 on microvm with this firmware, against the same
image booted the way it is today (firmware, boot loader, PCI):

	firmware	microvm + qboot
QEMU start to a logged-in shell	7.05 s	3.45 s
kernel boot time	--	507 ms

Disk over virtio-mmio, network over virtio-mmio, vioif0 configured and
routing, and an SSH login: all confirmed on a freshly built image.

Not included: pvh.bin

QEMU also ships pvh.bin, the option rom that performs the PVH handover on the
machine types whose firmware can't do it themselves — it is what makes
-kernel with a PVH ELF work on q35, for instance. It is deliberately left
out. It is not needed on microvm, where qboot does the handover, and while
QEMU otherwise probes for it and logs rom: file pvh.bin: error Failed to open file on every boot when it is absent, that probe does not happen when option
roms are disabled — which is what the consumer passes
(microvm,…,x-option-roms=off). Verified against this QEMU build both ways.

Tests

test.rb asserts the exact set of files in each tarball, so the new name is
added there.

Consumer

cross-platform-actions/action decides whether it can take the fast path by
looking for share/qemu/qboot.rom next to the kernel its image bundle carries;
with either file missing it boots the way it does today. So this can land and be
released on its own, and nothing changes for anyone until the action's pinned
resources version is bumped.