Split the keyboard onto its own translucent OpenXR quad

Expand the on-screen keyboard to a full US layout (letters, digits,
punctuation, Shift layer, Tab, arrows, F1-F12, one-shot Ctrl/Alt
modifiers), make it a persistent, movable, closeable panel via a
title-bar drag handle, and lower its opacity.

Previously the keyboard was just a second panel swapped into the same
quad as the menu launcher, which made the launcher translucent too and
made the keyboard and menu mutually exclusive. Extract the shared
swapchain/JNI/touch-dispatch plumbing into two generic, reusable
modules - xr_swapchain.c (swapchain + per-image FBO setup) and
xr_overlay.c (an off-screen Android View rendered into its own OpenXR
quad, hit-tested via a laser pointer) - and make the menu launcher and
keyboard two independent XrOverlay instances instead of one. The
controller's menu button now only opens/closes the launcher; the
launcher's "Keyboard" button only opens the keyboard - so the keyboard
can stay up while picking something from the menu, and only the
keyboard's own Close button hides it.

xr_menu.c/.h are gone, fully absorbed into xr_overlay.c. On the Java
side, OverlayPanel.java carries the shared off-screen-render/touch/
cursor plumbing that MenuOverlay and the new KeyboardOverlay both
subclass.

android/app/src/main/cpp/xr_input.h

@@ -1,11 +1,13 @@
 // Controller input for questshock's immersive Quest build: one OpenXR
 // action set (aim pose + trigger click per hand, a menu-toggle button on
-// the left controller) plus ray/quad hit-testing. While the menu quad
-// (xr_menu.c) is hidden, this tests against the game quad xr_session.c
-// submits and draws a small reticle where each hand's aim ray crosses it;
-// while the menu is visible, it tests against the menu quad instead and
-// forwards trigger edges as synthetic touches (no reticle - the menu's
-// own content comes from MenuOverlay's rendered Bitmap).
+// the left controller) plus ray/quad hit-testing. While neither the menu
+// launcher nor keyboard overlay (see xr_overlay.h, xr_session.c) is
+// visible, this tests against the game quad xr_session.c submits and draws
+// a small reticle where each hand's aim ray crosses it; while either
+// overlay is visible, it tests against that overlay's quad instead (the
+// keyboard is tried first) and forwards trigger edges as synthetic touches
+// (no reticle - each overlay's own content comes from its Java view's
+// rendered Bitmap).
 #ifndef QUESTSHOCK_XR_INPUT_H
 #define QUESTSHOCK_XR_INPUT_H