Give the game quad the same laser-beam pointer as the overlays

Aiming looked and behaved differently depending on whether the
keyboard/menu was open: xr_input_try_overlay() claimed a hand's ray for
its overlay whenever the overlay was merely visible, regardless of
whether the ray was actually pointed at it - so with the keyboard open,
aiming at the main game screen still showed a beam terminating at the
keyboard's fixed depth, while closing the keyboard swapped in the old
flat cross-shaped reticle at whatever the ray was really pointing at.

Only claim an overlay when the ray is actually relevant this frame - a
real hit, or a touch/drag begun on a previous frame still pending
release - so a visible-but-unaimed-at overlay now falls through to the
next-priority target. Give the game quad its own hit-test
(xr_input_try_game_quad()) and the same billboarded laser-beam
treatment as the overlays instead of the old flat reticle, so aiming
looks and behaves identically everywhere - overlay open or not. The
old reticle GL program/shaders are now fully dead and removed. No
click/touch dispatch is added to the game quad itself; that's future
work.

android/app/src/main/cpp/xr_session.c

@@ -350,14 +350,13 @@ void xr_frame_end(void) {
     if (g_session == XR_NULL_HANDLE)
         return;
 
-    // Draw the laser-pointer reticle into the still-bound game swapchain
-    // framebuffer before releasing it, so it composites on top of whatever
-    // this frame's game content already drew there. Syncing actions
-    // happens even when there's nothing to draw (no acquired image this
-    // frame), so edge detection (trigger/menu-button clicks) doesn't miss a
-    // frame. Only ever draws while neither overlay is visible (see
-    // xr_input.c) - the menu/keyboard render into their own independent
-    // swapchain images below.
+    // Syncs actions and hit-tests/dispatches each hand's ray against
+    // keyboard/menu/game quad (see xr_input.c) before the game swapchain
+    // image is released below - this always runs, even when there's
+    // nothing to draw (no acquired image this frame), so edge detection
+    // (trigger/menu-button clicks) doesn't miss a frame. Any resulting
+    // laser-beam quads are submitted as their own composition layers
+    // further down, not drawn into the game swapchain itself.
     if (xr_is_session_running())
         xr_input_sync_and_draw(g_local_space, g_predicted_display_time,
                                 g_have_acquired_game_image);
@@ -374,8 +373,8 @@ void xr_frame_end(void) {
     // xr_overlay_render_and_build_layer()) any time before xrEndFrame,
     // unlike the game quad there's no per-frame engine rendering to wrap
     // around here, just each overlay's own blit - and, per hand, a
-    // laser-beam quad while that hand's ray is aimed at one of those two
-    // overlays (see xr_input_get_beam_layer()).
+    // laser-beam quad while that hand's ray is aimed at the keyboard,
+    // menu, or the game quad itself (see xr_input_get_beam_layer()).
     XrCompositionLayerQuad gameQuad = {XR_TYPE_COMPOSITION_LAYER_QUAD};
     gameQuad.space = g_local_space;
     gameQuad.eyeVisibility = XR_EYE_VISIBILITY_BOTH;