Support creating BGR;15, BGR;16 and BGR;24 images, but drop support for BGR;32

[radarhere]

#6769 (comment) mentioned that creating BGR images does not work. Image.new("BGR;15", (1, 1)) does not work, and neither does BGR;16, BGR;24 or BGR;32.

So what are these modes?

Pillow/src/libImaging/Unpack.c

Lines 691 to 693 in 3b4b77b

	ImagingUnpackBGR15(UINT8 *out, const UINT8 *in, int pixels) {
	int i, pixel;
	/* RGB, reversed bytes, 5 bits per pixel */

Pillow/src/libImaging/Unpack.c

Lines 736 to 738 in 3b4b77b

	ImagingUnpackBGR16(UINT8 *out, const UINT8 *in, int pixels) {
	int i, pixel;
	/* RGB, reversed bytes, 5/6/5 bits per pixel */

So with that pattern, BGR;24 would allow 8 bits per channel, the same size as an RGB channel. And yes, when converting, the values are just reversed.

Pillow/src/libImaging/Convert.c

Lines 285 to 291 in 3b4b77b

	rgb2bgr24(UINT8 *out, const UINT8 *in, int xsize) {
	int x;
	for (x = 0; x < xsize; x++, in += 4) {
	*out++ = in[2];
	*out++ = in[1];
	*out++ = in[0];
	}

So this PR adds support for creating images with those three image modes.

Continuing on, with that pattern, one could imagine that BGR;32 is a mode that supports 10 or 11-bit values for each channel.

However, there isn't any concrete information about that. Pillow doesn't currently support converting images to BGR;32, nor does it support any kind of unpacking with this mode.

In fact, the only code about this mode is

Pillow/src/libImaging/Storage.c

Lines 155 to 161 in 079caf6

	} else if (strcmp(mode, "BGR;32") == 0) {
	/* EXPERIMENTAL */
	/* 32-bit reversed true colour */
	im->bands = 1;
	im->pixelsize = 4;
	im->linesize = (xsize * 4 + 3) & -4;
	im->type = IMAGING_TYPE_SPECIAL;

which I think can't be accessed through our Python API without other support for the mode, and

Pillow/src/PIL/ImageMode.py

Line 64 in 079caf6

"BGR;32": ("RGB", "L", ("B", "G", "R"), endian + "u4"),

which doesn't offer any value to the user if nothing else can be done with this mode.

So if ImageMode has the only functionality that would change for users (and it has only been in there since #5935), I'm going to suggest just dropping support for BGR;32 without deprecation - there isn't any demonstrated need for BGR;32, and we would just be inventing a mode by trying to specify what it is.

[radarhere]

Later in this file, IMAGE_MODES2 are tested to raise "color must be int or single-element tuple", while IMAGE_MODES1 are tested to raise "color must be int or tuple". This makes sense, as all IMAGE_MODES2 are single channel, while IMAGE_MODES1 have multiple channels.

[radarhere]

This error came from converting an image to a mode that putpixel was unable to getink with. However, all modes that an image can be converted to are now supported by getink after this PR.

The error should still be in C in case we break something in the future, but I don't think it can be tested.

[hugovk]

Let's also include this in release notes.