nested separator in to_ngff_zarr, fixed napari display problem

[GFleishman]

This fixes #45

I noticed calls to to_zarr in the to_multiscales function as well, but I think they're just cache for large files and not meant as ome-ngff-zarr outputs so I did not add a dimension separator for them.

You can also specify the dimension separator when you create the array (i.e. zarr.creation.open_array) but since you don't always do this explicitly I let the dask.array.to_zarr function do it.

Not sure if you want the dimension separator to be a user settable thing instead of hardcoded like this? If it's going to be standard practice for ome-ngff-zarr to use '/' and if some programs won't even support '.' then maybe compulsory like this is better, but your choice.

[GFleishman]

I have no idea how adding a keyword argument to an internal function would cause doc build to fail?

[thewtex]

@GFleishman thank you so much for a addressing this!! 💯 🥇

@joshmoore added this to the OME-Zarr spec and the functionality to Zarr Python -- he can correct me, but I believe it is not the default for backwards-compatibility reasons.

[thewtex]

I have no idea how adding a keyword argument to an internal function would cause doc build to fail?

@GFleishman I likely added the initial docs after you created the branch for this PR.