feat/global concurrency limit

[d-v-b]

Makes the concurrency limit global, rather than per-function.

I'm not emotionally attached to this PR -- it's largely the work of claude code. Lets use this as a starting point for improving on #3526

[dcherian]

Nice, the other one that bugs me when profiling is

zarr-python/src/zarr/codecs/zstd.py

Line 79 in b3e9aed

return await asyncio.to_thread(

[maxrjones]

@d-v-b do you have thoughts on how downstream libraries would interact with Zarr's concurrency limit? Would those set there own concurrency approaches (e.g., global or per function) or could there be a way to share the limit with Zarr?

[d-v-b]

@maxrjones this PR is moving away from a global concurrency limit because it's actually very hard to implement a top-down concurrency control in our codebase. the new direction I'm taking with this PR is for each store to set its own concurrency limit. for stateless stores like local and remote (basically anything except zip), concurrency-sensitive applications should be able to cheaply create store instances with concurrency limits tuned to the needs of the application.