v2 spec: add optional dimension_separator (see #707) (#715)

* v2 spec: add optional dimension_separator (see #707)

Various implementations allow for defining the separator between the
dimension indexes when writing chunks:

 * n5-zarr defines a `dimensionSeparator` parameter;
 * zarr-python's NestedDirectoryStore does so by default
 * and FSStore provides a `key_separator` parameter;
 * tensorstore has a `key_encoding` parameter; and
 * jzarr is looking to add the same functionality.

When writing an array, it is straight-forward to set this separator
and have arrays properly configured. Consumers of such arrays,
however, must either know *a priori* if their arrays use a
non-default separator or must loop through all possible chunks keys
searching for the right one.

By defining adding an optional metadata key to the .zarray, we:

 * preserve the efficient configuration of arrays
 * while keeping the v2 spec backwards compatible.

The primary downsides are that this will be the first optional metadata
value in the v2 spec and therefore we don't have a strong understanding
of how that will play out, and datasets which were previously written
with non-default separators will need updating in order to enable the
detection though that is no worse than the current situation.

* Update dim. sep. description after feedback

* Remove `MUST NOT` restriction for other keys

Author: joshmoore

docs/spec/v2.rst

@@ -78,7 +78,18 @@ filters
     filters are to be applied. Each codec configuration object MUST contain a
     ``"id"`` key identifying the codec to be used.
 
-Other keys MUST NOT be present within the metadata object.
+The following keys MAY be present within the object:
+
+dimension_separator
+    If present, either the string ``"."`` or ``"/""`` definining the separator placed
+    between the dimensions of a chunk. If the value is not set, then the
+    default MUST be assumed to be ``"."``, leading to chunk keys of the form "0.0".
+    Arrays defined with ``"/"`` as the dimension separator can be considered to have
+    nested, or hierarchical, keys of the form "0/0" that SHOULD where possible
+    produce a directory-like structure.
+
+Other keys SHOULD NOT be present within the metadata object and SHOULD be
+ignored by implementations.
 
 For example, the JSON object below defines a 2-dimensional array of 64-bit
 little-endian floating point numbers with 10000 rows and 10000 columns, divided