fix/normalize storage paths

[d-v-b]

This PR adds some of the path normalization logic from zarr v2 into v3. I largely copied this function as-is with a few tweaks. That function is actually not terribly strict as far as path parsing is concerned, so I'm open to requests that we make it stricter. The main thing to note is that normalize_path (the new name for that function) strips leading / characters from strings, which ensures that paths are relative.

I wired this function up to make_store_path, which previously didn't take path as a parameter (now it does). This led to some nice code deletion opportunities in our various creation routines.

Something that always bugged me in zarr v2 was use of None as a default value for types where there's already a default value. In the case of strings, the empty string '' is a perfectly good default value, and so allowing None is just noise IMO. I was tempted to try and remove None as a valid path argument in this PR, but I held back. If people agree that None is a silly default for a stringy value like path when we can just use '' instead, then I can make that change as well.

Fixes #2357

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]

Good stuff @d-v-b - I'm glad we're moving path into make_store_path.

[TomAugspurger]

Thanks, a couple questions about the implementation.

One meta-comment I've been thinking about, probably for a future PR: we could define PathLike as a NewType. The user-facing API could accept str | PathLike, and internally we could use just PathLike. Then we can verify with mypy that we've normalized all paths provided by the user.