Remove some allocations from HDR Decoder

[JulianKnodt]

A larger change was proposed in #1599,
but this is intended to fix #1882 precisely.

It adds extra trait implementations to Pixels, and removes the allocation while keeping the API the same.

[fintelia]

I've only skimmed it, but this PR looks kinda hard to review because moves around a bunch of finicky code.

One thing that particularly stands out to me though is that it uses a macro to generate generic, unsafe trait impls, on a public type. That's both a public API addition and inserts new unsafe code to the library. Potentially hard to justify for a minor perf improvement

[JulianKnodt]

One alternative is to create a clone of the image_transform which instead returns the colors in place.

Other than exposing an unsafe impl directly to the users, it's also possible to directly transmute the underlying types at the point where the bytemuck cast was added. I wasn't sure if that would be more or less preferred.

[fintelia]

Looking though this now, the PR basically just changes a memcpy into an unsafe transmute? That's not an improvement IMO. We'd ideally like this crate to be #[forbid(unsafe_code)], and while we're not quite there yet, I'd really rather not add any more unsafe in the meantime

[JulianKnodt]

For me, as long as the unsafe code is entirely within the confines of the API and with controlled types, then it's fine to introduce. But that's a personal opinion, so I've ripped it out & should be cleaner now.