Faster JPEG decoding with jpeg_decoder

[Shnatsel]

Avoid a memset() + memcpy() of the entire decompressed image, saving 10%-15% of the time in decoding JPEGs as measured on

ImageReader::open(input)?.with_guessed_format()?.decode()?;

---

Supersedes #1878 but only implements JPEG, not BMP. I'll file issues for BMP and HDR.

---

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

[fintelia]

This converts decoder_to_vec from an internal API to a public API. Before we go down that path, I'd like to understand whether it would be possible for zune-jpeg to conform to the same interface we already use.

@etemesi254 would it be possible to add a decode_into method to zune-jpeg so users can pass an already allocated/initialized buffer?

fn decode_into(&mut self, buf: &mut [u8]) -> Result<(), Error> { ... }

[etemesi254]

Possible

Should it be a hard error if space is too small or?

[HeroicKatora]

When it's too small, yes, hard error. When it's too large, it's your choice. Allowing is actually easier, the extra space might be useful padding. (As in, the extra bytes might make the whole slice castable to [__m256d]). But definitely not critical.

[etemesi254]

https://docs.rs/zune-jpeg/0.3.13/zune_jpeg/struct.JpegDecoder.html#method.decode_into

[Shnatsel]

I switched the zune_jpeg integration to use decode_into(), so now this PR is only a win for jpeg_decoder.

As a result this now conflicts with #1877