Allow optional RawDisplayHandle in InstanceDescriptor

[MarijnS95]

Connections
Probably supersedes #7969
Fixes #5505
Fixes #3176
Fixes #7965

Description
This allows platforms like GLES with EGL context backend to properly initialize such that their EGLDisplay and EGLContext are compatible with an incoming Surface, which is otherwise impossible if not for hotpatching the context (and loosing all resources created on it) when a surface comes in and that compositor connection becomes known.

This hotpatching is known to break quite a few systems and initialization ordering (i.e. the alternative is forcing users to create surfaces before querying adapters, which isn't feasible on platform like Android), and is better avoided or at least made possible by using the (Raw)DisplayHandle abstraction provided by raw_display_handle in the way it's intended to be used (additionally, removing it from the surface would be a sensible decision). This was suggested long ago in #6211 (comment).

There may however be cases where users want to initialize multiple Instances or perhaps Adapters for independent RawDisplayHandles, and certain backends may be designed specifically to cope with this (i.e. Vulkan).

Note that this PR does nothing to address many other soundness problems inside the EGL backend.

Testing
Using a Wayland compositor with:

WGPU_BACKEND=gl cargo r -p wgpu-examples -- shadow

Squash or Rebase?
rebase

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[alextechcc]

Wow this cleans up a ton of code. Wonderful!

Have you thought about putting the display connection into GlBackendOptions? https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-types/src/instance.rs#L321

Obviously it's already been mentioned that the vulkan backend could benefit from this, though that means we could also chuck the parameter in that struct too if we're being selective. Just thinking of minimizing the blast radius of these changes. As it stands, I think anyone who constructs an InstanceDescriptor has the "breaking change" with this PR that they need to specify something for display. Not sure how breaking changes are handled with wgpu.

I haven't had much time to work on this for a while, but I'm planning to try this with bevy at some point.

EDIT: I got bevy working with this PR. I'm not sure if I'm stepping on any toes here but bevy has its winit crate depend on the crate doing wgpu stuff, so it feels pretty wonky - but I can move around the types such that I have access to the display handle immediately and pass it to the instance descriptor. It seems there's a good amount of thread safety related stuff I have to read through, and if I want to make GL a viable option again I probably should make this a little less annoying: bevyengine/bevy#18932 and this bevyengine/bevy#13115