Faster BMP and JPEG decoding with any backend

[Shnatsel]

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

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

---

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

[Shnatsel]

Curiously this does not change the peak memory usage reported by time, and I don't understand why not. I'd expect it to be lower now that we don't have to keep two copies of the image in memory at the peak. Replacing with_capacity() with new() didn't change it either.

[Shnatsel]

This exposed a latent bug in TGA decoder - streaming decoding never worked correctly, but now it's causing a panic on the tests. I don't know enough about TGA to debug this.

[fintelia]

Thanks for making this PR! The performance observations are super valuable for optimizing.

I'm a bit torn about whether to merge this as is. Special casing into_reader().read_to_end() (when called with an empty Vec) as being the most performant way to use a decoder feels like an abuse of all the APIs involved.

A skim of the BMP decoder suggests that it might not be too much work to avoid the copy_from_slice call and decode directly into the output buffer. This might not be ideal for JPEG though since jpeg-decoder and zune-jpeg don't seem to have APIs to decode into a pre-allocated buffer.

[Shnatsel]

That's fair, it did strike me as a bit of an abuse of the API.

How about instead of having a single decoder_to_vec function that calls reads, we add decode_to_vec to the Decoder trait, with the version from before this PR as the default implementation? That should let us specialize the JPEG implementation without creating weird quirks that affect all decoders.

[Shnatsel]

Closing this in favor of #1879