Steps to reproduce:
1. Open the attached user's project with their relevant version (BugReport2022.zip) with 2022.2.18f1
2. Go to "Scenes/DemoScene.unity" and open the Scenes/DemoScene
3. Check Project Settings->XR Plug-in Management and make sure "Initialize XR on Startup" is checked and OpenXR is set as the XR provider. Then check Project Settings->XR Plug-in Management->OpenXR and make sure the "Mock HMD" feature is checked.
4. Open the Profiler window, make sure the CPU Usage module is visible, and enter Play Mode
5. In the Hierarchy window, enable Camera-Target-Eye-Both and observe the change in the profiler window. This camera renders to the main render target, and should not cause an increase in Gfx.WaitForRenderThread in every case.
6. In the Hierarchy window, enable Camera-Target-Eye-None, observe the change in the profiler window, and disable it. This camera renders to the desktop mirror view.
7. In the Hierarchy window, enable Camera-Target-RenderTexture, observe the change in the profiler window, and disable it. This camera renders to a render texture.
8. Try enabling multiple cameras, or disabling the Main Camera
9. Exit Play Mode, disable "Initialize XR on Startup" in the XR Plug-in managment. Enter playmode and repeat 5-8.
10. Change the GraphicsAPI to other ones, e.g D3D11, D3D12, Vulkan and repeat steps 5-9

Expected results: Additional Camera with Non-XR render target does not cause Gfx.WaitForRenderThread to consume most of the frame time
Actual Results: Additional Camera with Non-XR render target causes Gfx.WaitForRenderThread to consume most of the frame time

Reproducible in: URP 13.1.9, 14.0.7, 15.0.5, 16.0.1 (2022.1.24f1, 2022.2.18f1, 2023.1.0b15, 2023.2.0a13)
Not reproducible in: URP 10.10.1, 12.1.11 (2020.3.47f1, 2021.3.24f1)
Could not test below 2022.1.20f1 due to package errors when downgrading

Notes:
-Using OpenXR in 2022.2 and above, enabling an additional camera that renders to a non-VR rendertarget causes Gfx.WaitForRenderThread-Semaphore.WaitForSignal to go from taking from less than a millisecond to taking several tens of milliseconds.
-D3D11 shows extremely inconsistent times that rapidly spike between 1 to 120 ms, while Vulkan and D3D12 show mostly consistent times in the 10-30 ms range
-On Vulkan, if the extra camera is set to render to "Eye None" (the desktop view) Gfx.WaitForRenderThread rapidly spikes between 30 and 15 ms while if it is set to render to a render texture it stays consistent at ~10ms
-Additionally, when using D3D12 or Vulkan as the graphics API this happens even when OpenXR is not enabled to a much lesser extent, with Gfx.WaitForRenderThread going from 0 to several milliseconds
-Enabling cameras that render to both eyes has no effect on Gfx.WaitForRenderThread, and enabling additional monoscopic cameras beyond the first does not cause Gfx.WaitForRenderThread to grow significantly larger.

*Please refer to the comments for newer details.