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_swapchain.c

@@ -146,8 +146,7 @@ bool xr_swapchain_acquire(XrInstance instance, XrSwapchainState *state) {
     // gl4es's own (linked, not dlsym'd) bind - this targets an FBO id gl4es
     // itself created (see xr_swapchain_create()), so its own "current FBO"
     // bookkeeping updates correctly and its immediate-mode draw calls
-    // (android_draw_surface_as_quad(), the laser reticle) land in the right
-    // place.
+    // (android_draw_surface_as_quad()) land in the right place.
     glBindFramebuffer(GL_FRAMEBUFFER, state->fbos[imageIndex]);
     glViewport(0, 0, state->width, state->height);
     return true;