Add OpenEXR support for single-channel Luma32F images

[ChrisJr404]

Fixes #3016.

Now that ColorType::Luma32F exists, this teaches the OpenEXR codec to read and write single-channel 32-bit float luma images, which previously failed.

Behavior

Following the OpenEXR channel-naming recommendation, luma is stored in a channel named Y.

• Decoder: layer selection now prefers a non-deep RGB(A) layer (unchanged), and falls back to a non-deep Y-only layer, which is decoded as Luma32F. When a file contains both RGB and Y channels, RGB is still preferred.
• Encoder: ExtendedColorType::L32F buffers are written to a single Y channel.

So the example from the issue now works:

let image = ImageBuffer::from_fn(16, 16, |x, y| Luma([(x * y) as f32 / 225.0]));
image.save("test.exr").unwrap();

Luma + alpha is intentionally left out of scope, as noted in the issue.

Tests

Added roundtrip_luma (generate a Luma32F image, encode, decode, compare), mirroring the existing roundtrip_rgb/roundtrip_rgba tests. The decoder is exercised on a real Y-channel .exr produced by the new encoder path. All existing OpenEXR tests still pass, confirming RGB/RGBA decoding is unchanged.

cargo test --features exr,hdr --lib codecs::openexr — 6 passed. cargo clippy --features exr — no warnings. cargo fmt --check — clean.

[RunDevelopment]

https://github.com/image-rs/organization/blob/main/CONTRIBUTING.md#llm-policy

Given that you made >30 PRs to >15 repos yesterday and the LLM-speak in your PR description, I'm going to assume an LLM was involved substantually.