Support 5/1-bit encoded TGA images.

[red-001]

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

The decoder does the same thing as the BMP decoder, and converts 16-bit and 15-bit packed pixels to 24/32-bit ones on load.

This change implements #559 .

[sophie-h]

Is there anything missing to merge this? This appeared in the GdkPixbuf tests https://gitlab.gnome.org/GNOME/glycin/-/issues/147

[fintelia]

I think it is a matter of rebasing and then doing a full read-through of the TGA decoder to double check that the rest of the code isn't making assumptions that've been broken.

[nickbabcock]

There is a bit of a correctness issue here.

The tga implementation assumes that the pixel attributes bits represent the alpha channel, but for images that lack the TGA 2.0 extension area, it is ambiguous how to interpret these bits, as these bits could also be interpreted as overlay data.

This PR assumes a pixel attribute bit of 0 is equivalent to alpha=0, which yields fully transparent images where imagemagick, paint.net, and other image viewers are opaque as they either skip this data or assume it to be overlay data, and 0 means opaque.

The issue is apparent in this PR for the utc16.tga. The committed testsuite file is fully transparent, but it should be opaque.

To be conformant with the ecosystem, this single bit attribute should be skipped (ie: R5_G5_B5_COLOR_MASK should be used in all situations)