Check Opengl version is 3.3+ before creating a GL context over a GL ES context

[Rapdorian]

Connections
#5989

Description
Describe what problem this is solving, and how it's solved.
When creating a GL context wgpu prefers GL over GL ES if GL is available, regardless of version. If GL ES 3.1 is available and GL 3.3 is not (but an older GL is) wgpu is not able to create the GL ES context

If GL is supported I am creating a context of any version to check the GL version supported, if less than GL 3.3 we try to build a GL ES context instead of a GL context.

Testing
Explain how this change is tested.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[Wumpf]

Beyond a few nits looking good!
Also, please add a changelog entry, this is definitely a change users want to be able to read up upon :)

Maybe @valaphee who did a lot of the non-es OpenGL support previously wants to have a look as well?

[valaphee]

Personally I would handle the error rather than of preventing it. (would also remove unsafe and unwrap, and from_loader_function is quite heavy, as it gathers all function pointers)

e.g. https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-hal/src/gles/egl.rs#L609 fails because of https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-hal/src/gles/egl.rs#L554

and if it fails and OpenGL is used, then I would bind the OPENGL_ES_API and try again as this is the unlikely-path anyway.

[Rapdorian]

I've reworked the changes wrt @valaphee's recommendation.
The code now lets the GL context creation fails and then retrys with GLES.

[Wumpf]

ah this makes sense. Thank you @valaphee for pointing this out and @Rapdorian for improving accordingly!
Style suggestion for readability (anything but 20 line match head plz 😄 ), otherwise I think we're good

[Wumpf]

thanks again!