Add PolyBuffer and use it to handle 8/16-bit conversion in LXLayeredComponent.

[zestyping]

It's a major goal of this project to support existing 8-bit effects and patterns unchanged alongside new 16-bit effects and patterns, because it isn't practical to have to port all effects and patterns to run in 16-bit colour in one huge swoop.

A good place to start reviewing is the new class PolyBuffer.

This PR introduces PolyBuffer, a useful tool for handling 8-bit/16-bit conversions. It encapsulates a pair of colour buffers—an 8-bit colour buffer and a 16-bit colour buffer—and converts between them as needed, whenever anyone requests the data in a different colour depth than what was last written. It keeps track of which buffers are fresh or stale, so that it can automatically convert the data as needed without wasting time on unnecessary conversions.

LXLayeredComponent is the base for LXEffect and LXPattern. Its colour buffer is now a PolyBuffer, and it exposes its two arrays via its typeless getArray() method.

An added twist is that LXLayeredComponent supports two modes of operation already: it can either allocate and own its own buffer (which is what patterns do), or it can write to and modify an externally provided LXBuffer object (which is what effects do). The Buffered marker interface is used to select between these two modes.

[kylefleming]

We should consider separating the color space with the color depth. For example, an additive blend would request that the color buffers be in linear color space but wouldn't care the color depth.

This becomes especially important in java where we have to specify the type (int vs long) but could use the same variable for both linear 48-bit and gamma compressed 48-bit. (for example, if statements checking for color depth in order to declare the correct type only needs to check the color depth)

[kylefleming]

I would consider having something akin to IntBuffer and LongBuffer as subclasses of Buffer and then having public IntBuffer getIntBuffer() or public IntBuffer getIntBuffer(Space space) (as well as the long versions). Then in those methods it could double-check that the Buffer is of the correct type before casting to the buffer subclass in order to call the appropriate method on the buffer subclass. The purpose of this would be to get rid of unsafe casts and to avoid returning Object from methods.