This PR adds aBytes dtype that is nearly identical to the existingVariableLengthBytes dtype save a few differences:

• the V3 JSON form is"bytes" instead of"variable_length_bytes"
• The fill value representation is an array of ints, instead of a base64-encoded string
• Bytes is consistent witha published spec, instead of not being described by a spec.

The latter point is the most important.

BecauseBytes is nearly identical toVariableLengthBytes, it could be a drop-in replacement forVariableLengthBytes, save for the JSON fill value encoding differences between the two codecs, which raises two questions:

• is base64 encoding a bytestring a better or worse JSON serialization than representing the same bytestring as an array of integers?
• could (or should) we amend the bytes data type spec to recommend reading (or reading and writing) both fill value encodings? If so, thebytes data type and thevariable_length_bytes data types could be fused completely.

Since zarr python 2.x was saving bytes fill values as base64-encoded strings, there's a bit of inertia there. Would also be good to hear thoughts from other implementers (@LDeakin ,@jbms,@manzt )