There are some cases when message contains byte array of fixed size which is not an ASCII string - e.g. hmac signatures. Declaring them as fixed-size uint8 array currently generates only generic array accessor to put/get one element at a time. Declaring them as strings generate bulk put/get methods which accept byte[], but string semantics - e.g. charset - do not really apply to the field.
This PR adds bulk get/put methods for fixed-length data (described in the "Fixed-length data" section of the spec).

Encoder
public void putData(byte[] buffer, int offset, int length);
public void putData(DirectBuffer buffer, int offset, int length);
These methods behave like var-length counterparts, but pad smaller payloads to the required length with zeros. I couldn't find anything in the spec on the padding, but this looks like least-surprising behaviour - e.g. the following hypothetical code would behave as if new buffer is allocated every time, even if it's in fact reused

  int actualLength = fillData(data);
  encoder.putData(data, 0, actualLength)

Expected typical usage is actually that caller will provide all bytes.

Decoder
public int getData(byte[] buffer, int offset, int length);
public int getData(MutableDirectByteBuffer buffer, int offset, int length);
public void wrapData(DirectByteBuffer buffer);
These methods behave similar to var-length counterparts:

• read min of the provided and actual length
• getData will return 0 when decoding older version of the message w/o the field
• wrapData will result in empty buffer when decoding older version

It also seems like there was a bug when generated wrapData() did not properly handled older versions (missing return) - this should be fixed.