Bug 96971

	With 24/32-bit xwd files, xv swaps the red and blue channels.
	With 16-bit xwd files, the image is very dark green (almost black).

	Both problems are caused by hard-coding the channel order and
	offsets, rather than using the colour masks in the xwd header.

	xv reads the input into a 24-bit internal image, which is then
	displayed.  The lack of brightness in the 16-bit display is
	because the colour values are copied into the low-order bits of
	the internal pixmap rather than the high order bits.  The green
	hue is because the green channel has 6 bits, whereas red and
	blue only have 5 bits, making the green twice as (relatively)
	bright.
	
	Thanks to Callum Gibson for initial pointers to the bug as well
	as 16-bit dumps.

Fix: The following patch replaces the byte-swap routines as well - I
	initially suspected that the problem was at least partially
	caused by the non-portability of "union cheat".  Whilst that was
	not a problem, the resultant code is cleaner and I did not want
	to expend further effort removing the change.

	Rather than hard-coding the shift values (and the mask for 24-bit
	colour), the shift value is calculated from the mask during
	initialisation.  Since the low colour bits must be shifted left
	whilst all other shifts are right, each pixel colour is shifted
	so the MSB of the colour is in bit 31 and then shifted right 24
	bits to correctly locate the colour in an 8-bit field.
	
How-To-Repeat: 	Do a window or screen dump using xwd from a 24/32-bit TrueColor
	display.  Display the screen dump using xv.

	Do a window or screen dump using xwd from a 16-bit TrueColor
	display.  Display the screen dump using xv.