Fix GL BadDisplay by providing a wl_display handle (WIP on wgpu side too)

[alextechcc]

NOTE: This is a DRAFT and is based off of several WIP branches/pull requests, including one for WGPU. The commits are ugly, the code is ugly. I hope this can serve as a way to discuss if/how to get a raw display handle over to wgpu when initializing the wgpu instance.

Objective

• Fixes REGRESSION: wgpu panic BadDisplay after winit 0.30 on Wayland OpenGL #13923

WGPU GL appears to be completely broken on Wayland because if you enumerate adapters before creating a surface (which passes a wl_display handle from winit to the instance) - the GLES backend is forced to create a dummy display connection (https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-hal/src/gles/egl.rs#L901) - and these handles and all resources created with each-other are not compatible, so it is forced to reinitialize its contexts when it is passed the handle (https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-hal/src/gles/egl.rs#L1057), it does this in an unsound way which terminates GL sessions and other ugly side effects.

There is a WIP gfx-rs/wgpu#8012 to allow passing a RawDisplayHandle to a wgpu instance when constructing it - sidestepping all the ugly context re-initialization - making sure that the contexts are all valid.

Currently bevy does not seem to be set up to get a valid surface before creating the wgpu instance or requesting adapters. The order seems to be:

1. WinitPlugin is added, build() creates the event loop immediately (https://github.com/bevyengine/bevy/blob/main/crates/bevy_winit/src/lib.rs#L136), but does not create windows yet. At this point, it creates a DisplayHandleWrapper which would be perfect to throw into the wgpu instance, but unfortunately bevy_winit depends on bevy_render and not the other way around, so it is not possible for it to access this resource.
2. RenderPlugin is added, build() queries for a window that already exists to create a surface for, and to use the surface as a compatible_surface to pass to wgpu. I don't see how this could happen. It misses this, and thus initializes wgpu, doesn't make any surfaces or pass compatible surfaces. https://github.com/bevyengine/bevy/blob/main/crates/bevy_render/src/lib.rs#L384
3. It then enumerates adapters, locking us into the buggy path that will create BadDisplay.
4. about_to_wait() is called by winit, which creates windows

   bevy/crates/bevy_winit/src/state.rs

   Line 510 in d1aab7c

   create_windows(event_loop, create_window.get_mut(self.world_mut()));

   - but I believe this can only happen in the WinitAppRunner - after the app is started and running the event loop and gets a resumed event from Winit. At this point it's far too late to use this window handle.

So, the goal of this PR is to figure out a way to throw a RawDisplayHandle over to wgpu when initializing the instance so that the egl backend can function.

Solution

• bevy_window also provides RawDisplayHandle (https://github.com/bevyengine/bevy/blob/main/crates/bevy_window/src/raw_handle.rs#L61), and it is depended on by both bevy_winit and bevy_render so it's the ideal location to throw the RawDisplayHandle. It seems this is the place that bevy_render can get the contexts it needs, but does not seem to work as intended now due to windows being created way later.
• This current PR feels a bit wonky with how bevy_winit already immediately provides the RawDisplayHandle (https://github.com/bevyengine/bevy/blob/main/crates/bevy_winit/src/lib.rs#L136), but it's just a dependency cycle issue preventing bevy_render from using it immediately. I'm certainly open to suggestions.
• I'd really like to know how this line is intended to function: https://github.com/bevyengine/bevy/blob/main/crates/bevy_render/src/lib.rs#L379 - is it when you manually create winit windows yourself rather than waiting for the winit app runner to?

Testing

• This works on my AMDGPU machine when running any example: WGPU_BACKEND=gl cargo run --features wayland,bevy_render/decoupled_naga --example 2d_gizmos

[alextechcc]

Closing due to #20358