Writing 24bpp (depth=24, spp=3) PIX to BMP produces b0rked files

[GerHobbelt]

See also comment at #675 for code extract as sample code zip.

Relevant code sequence extract shown here (knowing pixReadWithHint is same as pixRead or BMP, but this was coded while looking at #675, where pixReadWithHint was initially used) :

	pix[5] = pixReadWithHint(DEMOPATH("test-rgba.bmp"), IFF_BMP);
	// identical to: pix[5] = pixRead(DEMOPATH("test-rgba.bmp"));

	d = pixGetDepth(pix[5]);
	assert(d == 32);
	spp = pixGetSpp(pix[5]);
	assert(spp == 4);
	pix[11] = pixConvert32To24(pix[5]);  // <<-- required to reproduce this issue: only happens for 24bpp PIX
	d = pixGetDepth(pix[11]);
	assert(d == 24);
	spp = pixGetSpp(pix[11]);
	assert(spp == 3);
	ret |= pixWrite("/tmp/lept/bmp-test/target-rgba24.bmp", pix[11], IFF_BMP);
	ret |= pixWrite("/tmp/lept/bmp-test/target-rgba24.png", pix[11], IFF_PNG);

Note that the expected output BMP filesize is around 15K (4 planes source is 20K; we dropped the A plane, so 25% size reduction estimate), but instead is a wild, quite large size.

Turns out d=24 will drive the bmp writer to use a cmapped / b<=8 code path, rather than the d=32/d=16 'full color' code path.

A pullreq with a patch is forthcoming.

(I need to extract/cherrypick that from my fork, so expect a ~30 mins delay on that.)

[GerHobbelt]

Closed & fixed as per #685.