Accept dictionaries for store argument

[TomAugspurger]

This updates how we handle a plain dictionary provided to open_group and friends so that the following works:

group = await zarr.api.asynchronous.open_group(store={}, mode="w")

The dictionary is interpreted as the store_dict argument of zarr.store.MemoryStore. This effectively mirrors the behavior of zarr-python v2, and I think doesn't introduce an ambiguity. Previously a TypeError was raised.

This change will make it slightly easier to get xarray's test suite running with zarr v3.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[jhamman]

After thinking a bit more about this, I'm a bit concerned that we may not be ready for a generic MutableMapping in the MemoryStore. What would happen if we tossed a zict.LMDB into the constructor? I suspect things would mostly work but maybe not?

[TomAugspurger]

I'm not sure how much faith to put in it, but the fact that mypy allows it gives me some comfort.

[d-v-b]

If we accept anything that implements MutableMapping here, then there's no guarantee that the store is actually in memory, since the __getitem__ and __setitem__ operations could be running arbitrary IO-ful code. This seems fine with me, as long as users know what they are getting into, and maybe a useful bridge for users who want some v2-style store behavior (but maybe a better name for the store would be MutableMappingStore?)

[TomAugspurger]

Ah, I see, the concern is specifically around the isinstance at https://github.com/zarr-developers/zarr-python/pull/2164/files#diff-9a2583a58394683284176a2d2db4df1e8ffafce4f34edc7a176c625863815518R99.

In that case, yes, I think we should narrow it to just accept dictionaries, where there's no ambiguity about whether a MemoryStore is appropriate.