By the spec, the ColorSpace key in JPXDecode image dictionaries is optional, and
if it's not present, the reader is supposed to parse the stream data and choose
an appropriate colorspace.

As of r9297, we just assume it's DeviceRGB. This need to be improved by adding
metadata extraction code to the jpx stream implementation and adding a
postscript operator through which the pdf interpreter can call this code to
obtain the required information. This is slightly complicated by the fact that a
ColorSpace key, if present, is supposed to override what's in the stream. So we
also need to communicate to the actual decoder whether this was the case, or
describe the colour space accurately enough that the effects are the same. This
includes extracting and ICC profile if one is present.

Both JPX implementations already obtain this information, but it's probably more
efficient to implement just the image box parsing in custom code, since it can
read only far enough to get the necessary data and return quickly. See
toolbin/jpxtopdf.c for an example of such an implementation.

As a more minor issue, the BitsPerComponent element is also ignored in favour of
whatever the stream produces. Right now we generally scale everything to 8 bits,
but once this mechanism is in place is can also be used to communicate the best
precision option to the pdf interpreter before the stream is decoded.

Test files are available attached to bugs 688159, 689058 and 689509. However,
they're all rgb, so some examples with other colour spaces must be made.