tga: decode 5-bit-per-primary images

[mstoeckl]

This is very loosely based on another PR to implement decoding of 5-bit-per-primary TGA images, #2303. That PR (also licensed MIT OR Apache-2.0) has not been updated in a bit more than a year, in which time there have been refactorings and other changes to the TGA decoder which would require additional work to resolve merge conflicts for. As a result, I expect it is unlikely that it will be updated this year, and am making this PR to try to have the feature implemented more quickly.

Notes:

• The decoder implementation ignores the "attribute bit" and does not interpret it as alpha, as recommended by the comment Support 5/1-bit encoded TGA images. #2303 (comment). I've found that old TGA images often set the attribute bit to zero, and found one which uses it for something other than an alpha channel.
• This adds an ExtendedColorType::Rgb5 enum entry to indicate the "type" of image data being provided. A precise description of the pixel format used by uncompressed true-color 5 bit-per-primary TGA images is DRM_FORMAT_XRGB1555, but I don't think going into such precision is appropriate for how ExtendedColorType is used.
• I'm taking as minimal of an approach as I can for this PR, and have skipped implementing encoding of TGA images with this format. (One thing I've been thinking of is rewriting the core parts of the TGA decoder to use a slice based framework, as in the mstoeckl/tga-slice branch, but that may a) require trait bound changes b) refactoring everything anyway; so I'd like to avoid moving around large chunks of the code twice, if I can.)
• I made the test images myself, and license them (and this PR) to match the image crate, specifically as MIT OR Apache-2.0. You may also use them under CC0.
• This should resolve Support for 15-bit and 16-bit TGA file formats #559.

Let me know if you'd like me to make any changes, split off the addition of ExtendedColor::Rgb5 into another commit, etc.

[fintelia]

I think this might be better as Rgb5x1 or similar to indicate that each pixel is actually 16 bits rather than 15.

[mstoeckl]

Done, but I should warn you that I think ExtendedColorType is starting to get stuck between two concepts: the in-memory layout of uncompressed arrays of pixel data (needed to extend ColorType), and the logical content of each numeric pixel value (which is just how many bits of float/uint each channel has, without stating an order or binary representation). The former is useful for direct access to uncompressed images; the latter for lossless conversions between image types (assuming compatible color representation information). I'd recommend splitting off the latter into a new type eventually.

[Shnatsel]

I love all the comments and added tests, it's all pretty clear to me.

This seems to be good to go, any outstanding concerns from the maintainers?