Move packages into a top-level workspace

[asinghvi17]

Moves Zarr and its eight component packages into sibling directories at the repository root. The root Project.toml contains only workspace membership; every local package dependency has a relative source path. Documentation stays in docs/, while the coverage and logo tooling environments remain outside the shared workspace.

Updates CI, documentation builds, coverage paths, CompatHelper, and TagBot for the new layout. Each package gets a standardized short README and a LICENSE.md symlink to the root license. All nine packages are version 0.11.0, with matching sibling dependency compatibility bounds.

The first commit contains only file moves: Git identifies all 71 as 100% identical renames. Configuration changes and documentation follow in separate commits.

Validation: the workspace resolves from a fresh manifest on Julia 1.13; all 31 focused package-location and registration checks pass. All relative source paths and license links were checked, workflow YAML parses, and git diff --check passes. Full CI and the documentation build have not been run locally.

[coveralls]

Coverage Report for CI Build 34696473871

Coverage decreased (-4.9%) to 90.488%

Details

• Coverage decreased (-4.9%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	2008
Covered Lines:	1817
Line Coverage:	90.49%
Coverage Strength:	5821.98 hits per line

---

💛 - Coveralls

[mkitti]

This will give us a Makie style layout and also allow for a top-level Project.toml that will define a workspace. Credit to @nhz2 for pushing us in this direction.

[lazarusA]

Overall looks very good to me, just 2 questions:

• all sub package components seem to start at version 0.10.1 but Zarr, which is as of now at 0.10.2, why the mismatch? Also, when this is over, the final version of Zarr will be 0.11.0 (a breaking release isn't? ). I'm just wondering where should we start the base versions of the sub packages.
• Also, I guess there are no issues to register new packages at this version levels?

[asinghvi17]

Good point, should just make them all 0.11.0 then

[lazarusA]

Good point, should just make them all 0.11.0 then

well... not sure. All sub packages are new, so is not normal to start with such high version numbers, plus they will diverge over time, so after a while it will not matter. I'm just curious about what is the best practice in this case, I don't know, do we match the version of the main package or do we start from 0.1.0 ?