Add basic JXL image support

[xangelix]

• I have followed the instructions in the PR template

Blocked by:

• Update MSRV from 1.76 to 1.77 #5322 jxl-oxide makes use of the array::each_mut API
• Use proper image crate URI and MIME support detection #5324
• jxl-oxide v0.10 --> Git source then needs to be replaced

Rationale

The image crate maintainer has made it clear that they do not intend to support JXL at this time, and likely won't be in the future either, see: image-rs/image#1979

For this reason, the jxl-oxide crate has just recently added support for the image crate format, see: tirr-c/jxl-oxide#162

JXL is a leading format (with yes, much less adoption than others) including various features that make it a compelling option. jxl-oxide is an appropriate crate choice as it has a history of being very well maintained, and (at least a couple months ago?) is the likely pickup for Chromium and Firefox support in the next year or so. I've lost the source on this one, but remember either the Chromium or Firefox devs officially stating they were unwilling to merge the C library in, but suggested continuing this rust port. The eventual crate being worked on to be implemented in Chromium and Firefox is https://github.com/libjxl/jxl-rs, however, jxl-oxide is still receiving active updates.

This is also especially interesting to implement as it allows high quality jxl support through WASM, irrespective of browser jxl support (which is poor at the moment).

This PR is a draft until jxl-oxide's v0.10 release, which adds built-in image crate compatibility. The other linked PRs should also come first. v0.10 was released https://github.com/tirr-c/jxl-oxide/releases/tag/0.10.0

Todo/Further Considerations

• Some image urls don't load after #5324 #5341 ~Possibly should await any further image crate support detection changes. JXL magic byte detection could be added if that is the route we want to go down.
• jxl-oxide uses rayon optionally to speed up decode. Is it fine leaving this feature for the caller to specify in their own Cargo.toml? (similar to how the image crate features are currently set up)
• Should this PR be expanded to include more JXL features? Or (more likely) worry about basic support for now, and do larger refactoring of image loaders in a new PR? (Multiple image formats support progressive decode)

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/5325-jxl-support
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

[lucasmerlin]

Great work! Unfortunately I think jpeg xl is a bit too niche in order to be included in egui as a extra image loader. You should instead release it as a 3rd party crate (e.g. egui_jxl) and add it to the wiki so other people can find it!