Add support for saving 16-bit images to pnm formats

[Enet4]

Should hopefully resolve #2430, as well as #1687. It takes the assumption that when an image is 16-bit and the encoder receives a &[u8], it means that the samples were in reality 16-bit and the slice was cast to a byte slice.

Summary

• add sample adaptation layer which recovers 16-bit samples from the original image buffer depending on the color type provided
  • Once this is done, the number of samples should match the expected number of samples, and the rest of the encoding process should simply work
• allow for RGB and RGB Alpha tuple types in header check
• add test suite save_pnm.rs and test sample images from pngsuite:
  • basi0g16.png: 16-bit grayscale image
  • basn2c16.png: 16-bit RGB image

Known caveat

• I am not entirely sure whether the assumption can be made in general, or whether it would be possible for someone to request 8-bit samples to be extended and encoded as 16-bit through the encoder.
• While this should also enable the encode to write PAM files, AFAIK PAM file decoding is not yet supported in the library.

[fintelia]

Thanks for this PR! I am in favor of adding 16-bit support here.

One concern is that the write_image should not require that users pass aligned slices. If the color type is a 16-bit per pixel format then the user is allowed to pass any native endian pixel data without worrying about alignment. One option to handle potentially misaligned inputs is to allocate a temporary Vec<u16> and copy the provided data into it. That adds some memory overhead, but should be pretty fast to implement.

[Enet4]

One option to handle potentially misaligned inputs is to allocate a temporary Vec<u16> and copy the provided data into it. That adds some memory overhead, but should be pretty fast to implement.

I'll see what I can do. The encoder implementation cannot switch the lifetime of the samples midway, so the best place to re-adapt the byte buffer (with an allocation if necessary) would be as early as possible in the impl.