GMMOS: USB keyboards on xHCI

The third micro driver: xhci.c with everything but finding a keyboard and
reading it taken out. It does not take over the live driver's state --
the kernel may have died inside that driver -- so each controller is
halted, reset and enumerated from nothing. Of the live driver it uses
the register mapping and the scratchpad pages the controller was lent
(DCBAA entry 0, read before the reset).

Root ports, and USB 2 hubs up to two deep (power, reset, route string,
transaction translator for a slow device behind a high-speed hub). A
boot-protocol keyboard interface gets Set Configuration, Set Protocol
boot, Set Idle, one interrupt IN endpoint and a Normal TRB, re-queued
after every report. No interrupts, no hot-plug, nothing that is not a
keyboard or a hub. A static 256 KB pool instead of the DMA allocator.

Checked under QEMU with the PS/2 controller switched off (i8042=off): a
USB keyboard on a root port, and one behind a hub, both type into the
GMMOS terminal. QEMU's hub is full speed, so the transaction-translator
path is not exercised.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4

kernel/gmmos/gmmos.c

@@ -49,7 +49,9 @@ static int     npcs;
 static int sw, sh, cw, ch;
 // Every micro driver, in the order they are tried. All that answer are
 // polled: a laptop has its own keyboard and maybe a USB one on the side.
-static const struct gmmos_kbd *const drivers[] = { &gmmos_ps2, &gmmos_i2c };
+static const struct gmmos_kbd *const drivers[] = {
+  &gmmos_ps2, &gmmos_i2c, &gmmos_xhci,
+};
 static const struct gmmos_kbd *kbds[NELEM(drivers)];
 static int nkbd;