fix: black bars display issue on quest3

[emawind84]

Fixes #20

[emawind84]

This PR fixes issue #20

[emawind84]

Root cause, found by static tracing (no device log needed here — it's a math bug, not a driver quirk):

The bug: two places compute a single "averaged" symmetric FOV from both eyes' actual per-eye FOVs, then apply that same averaged FOV to both eyes:

VR_GetVRProjection() in QzDoom_OpenXR.cpp (the "meta" branch) — used to build the render projection matrix.
TBXR_submitFrame() in TBXR_Common.cpp — used to set projection_layer_elements[eye].fov, i.e. what's declared to the OpenXR compositor as each eye's actual FOV.

The averaging does angleLeft = (eye0.angleLeft + eye1.angleLeft) / 2, etc. But angleLeft/angleRight are per-eye-local — eye 0's angleLeft is that eye's outward (temporal) side, while eye 1's angleLeft is that eye's inward (nasal) side. These aren't the same physical direction, so averaging them mixes outward and inward angles together. This only produces a harmless no-op if a headset's per-eye FOV is already close to left/right-symmetric — apparently true enough on Quest 2 to hide the bug. Quest 3's pancake-lens optics report more asymmetric per-eye FOV, so the average visibly shrinks the usable FOV on both outer edges — exactly the "black bars on both sides, most noticeable looking straight ahead, horizontal only" symptom, and consistent with the menu (which doesn't go through this path) being unaffected.

The fix: use each eye's own actual, unaveraged FOV in both places — matching what the "pico" branch already did correctly, and making sure the compositor is told the true FOV of what was actually rendered into each eye's swapchain.

[emawind84]

@DrBeef this fix could be of help for other ports