arm64: host-proxied ITS for MSI/LPI delivery to spawn kernels #16

Part of the arm64 port. Needed for any PCIe NIC or NVMe in a spawn.

An ITS has one command queue (MAPD/MAPTI/INV/DISCARD/MOVI) owned by exactly one kernel, so a spawn cannot run irq-gic-v3-its.c against a shared ITS. x86 has no analogue: MSI addresses name the destination LAPIC directly.

Design: host-proxied ITS.

• Spawn: a thin MSI irqdomain (drivers/irqchip/irq-gic-v3-its-mk.c or similar, selected when the instance DTB lists an ITS with a tenant property). alloc sends a ring message (multikernel_send_ipi_data()) asking the host to map device ID + event -> LPI -> collection (an RD of one of the spawn's CPUs) and returns the LPI. free, set_affinity (MOVI), irq_unmask/irq_mask (INV after config change) are proxied the same way. The spawn writes the device's MSI address (GITS_TRANSLATER, a constant) and data (event ID) itself, as the stock driver does.
• LPI configuration/pending tables: per-RD GICR_PROPBASER/GICR_PENDBASER. Decide whether the spawn allocates its own tables for its RDs (simplest isolation) or the host tells it the shared table; document the choice.
• Host: a message handler in kernel/multikernel/ calling a small exported ITS API (its_map_foreign_lpi(), its_unmap_foreign_lpi(), its_move_foreign_lpi()) added to irq-gic-v3-its.c, operating on collections that belong to non-host CPUs. The host must allocate those collections at spawn time and tear them down on halt (DISCARD everything owned by the instance) so a crashed spawn leaves no dangling LPIs.
• Multi-ITS systems: assigning a whole ITS to an instance is a later optimisation, not the base design.

Test on QEMU virt with its=on and a virtio-pci device assigned to the spawn.