zarr.open should fall back to opening a group

[TomAugspurger]

Closes #2309

I'm not happy with this implementation. I broke / fixed this in my consolidated metadata PR as well.

Relying on the exception type from open_array to decide whether to fall back to opening a group seems pretty fragile. I might spend a few minutes trying out an alternative way of doing things that'll be a bit more robust (potentially at the cost of some unnecessary I/O; but I think that's OK for open since open_group and open_array offer more direct ways of doing things).

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)

[d-v-b]

maybe we should create a specific exception for this case, since "valid document but the wrong node type" is different from "invalid document"

[TomAugspurger]

I might spend a few minutes trying out an alternative way of doing things that'll be a bit more robust

https://github.com/TomAugspurger/zarr-python/blob/tom/fix/batched-io/src/zarr/core/metadata/_io.py has the start of that. I like the idea of using match statements and an explicit list of files to read. There's still a decent chunk of work to do (figure out which cases we know we files to read and error if any are missing, then discover the actual zarr_format and node_type based on what we read and parse into the correct objects, and finally updating open and hopefully open_array and open_group to use that or something similar). I don't think I'll pursue this now.

[jhamman]

One test suggestion but otherwise this looks good to me.