### Godot version

4.1

### System information

Windows 10 - Godot 4.1.1 - Compatibility

### Issue description

When trying to use the Varjo XR3 headset (in OpenXR mode) with Godot 4 (with OpenXR and passthrough activated), the passthrough does not work, i.e. the scene is rendered on a black background instead of the camera stream.

It seems to me that are two problems in the openxr module, more precisely in the openx_api.cpp file (fixing them solves  the issue) : 

1. The XR_COMPOSITION_LAYER_BLEND_TEXTURE_SOURCE_ALPHA_BIT  is only set when the number of layers is > 1, which is fine for the Meta Quest headset but does not work for the Varjo since it only requires one layer. 
2. The environment blend mode XR_ENVIRONMENT_BLEND_MODE_ALPHA_BLEND  is only really set when the XRFbPassthrough extension is present, which is not the case with the Varjo runtime. 

I am not sure how to fix this without causing issues for other headsets.

1. Would it be an issue to always activate the XR_COMPOSITION_LAYER_BLEND_TEXTURE_SOURCE_ALPHA_BIT ? 
2. Could blend modes be activated even if they are not supported by an extension ? 





### Steps to reproduce

- Create a Godot 4 project with OpenXR activated in Compatibility mode
- Add the code to activate OpenXr and to enable passthrough : https://docs.godotengine.org/en/stable/tutorials/xr/openxr_passthrough.html#passthrough-extension
- Start the Varjo Base software and activate OpenXR
- Run the Godot project

### Minimal reproduction project

N/A
*   responsible for the initialization of all low level singletons and core types, and parsing
 *   command line arguments to configure things accordingly.
 *   If p_second_phase is true, it will chain into setup2() (default behavior). This is
 *   disabled on some platforms (Android, iOS) which trigger the second step in their own time.
 *
 * - setup2(p_main_tid_override) registers high level servers and singletons, displays the
 *   boot splash, then registers higher level types (scene, editor, etc.).
 *
 * - start() is the last step and that's where command line tools can run, or the main loop
 *   can be created eventually and the project settings put into action. That's also where
 *   the editor node is created, if relevant.
 *   start() does it own argument parsing for a subset of the command line arguments described
 *   in help, it's a bit messy and should be globalized with the setup() parsing somehow.
 */
Error Main::setup(const char *execpath, int argc, char *argv[], bool p_second_phase) {
	Thread::make_main_thread();
	set_current_thread_safe_for_nodes(true);
	OS::get_singleton()->initialize();
	
	
	OS::get_singleton()->benchmark_begin_measure("startup_begin");
	engine = memnew(Engine);
	MAIN_PRINT("Main: Initialize CORE");
	OS::get_singleton()->benchmark_begin_measure("core");
	register_core_types();
	register_core_driver_types();
	MAIN_PRINT("Main: Initialize Globals");
	input_map = memnew(InputMap);
	time_singleton = memnew(Time);
	globals = memnew(ProjectSettings);