More robust support for 1, 2 and 4 bit images

[mlinkert]

1, 2 and 4 bit images are currently supported, but not in the most flexible way. Instead of storing these images in their original bit depth, we automatically convert them to 8 bit data and throw away the original bit depth. We should do the following:

• use the type BufferedImage?.TYPE_BYTE_BINARY when constructing BufferedImages?
• add a new flag to the API to toggle how openBytes handles < 8 bit data - developers can choose whether to get original data (e.g. 1 byte represents 8 pixels), or expanded data (i.e. 1 byte represents 1 pixel)
• potentially add new pixel types to the OME data model (uint1, uint2, uint4, etc.)
• update the TIFF writer to export 1, 2 and 4 bit data

[jmoore]

imported from ​bio-formats:#344

[mlinkert]

Note that current versions of the OME-XML schema allow for a BIT type (i.e. uint1), so point 2 is partially resolved and point 4 can be done as part of #12599. Whether uint2/uint4 are still relevant for inclusion is probably up for debate.

The second point above is related to the discussion in #12599; if it's useful to have a way to get the packed representation, that might be best done through a ReaderWrapper? implementation.