Switch from pyzstd to compression.zstd

[avalentino]

[Description of PR]

Python v3.14 introduces the compression.zstd module (derived from pyzsrd).
For Python versions lower than v3.14 the backports.zstd module is now available.

This patch modifies teh test code to use compression.zsrd intead of the old and deprecated pyzstd module.

TODO:

• Unit tests and/or doctests in docstrings
• Tests pass locally
• Docstrings and API docs for any new/modified user-facing classes and functions
• Changes documented in docs/release.rst
• Docs build locally
• GitHub Actions CI passes
• Test coverage to 100% (Codecov passes)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 2.14%. Comparing base (e0ddee6) to head (f847f0c).

❌ Your project check has failed because the head coverage (2.14%) is below the target coverage (100.00%). You can increase the head coverage or adjust the target coverage.

❗ There is a different number of reports uploaded between BASE (e0ddee6) and HEAD (f847f0c). Click for more details.

HEAD has 20 uploads less than BASE

Flag	BASE (e0ddee6)	HEAD (f847f0c)
	23	3

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #818       +/-   ##
==========================================
- Coverage   99.33%   2.14%   -97.19%     
==========================================
  Files          26      26               
  Lines         898     884       -14     
==========================================
- Hits          892      19      -873     
- Misses          6     865      +859     

see 25 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[avalentino]

Failures seem to be unrelated to this PR.

[d-v-b]

@avalentino are you using zstd in the context of Zarr? because if so, would you mind opening a PR to make this change in zarr-python, which would allow us to no longer depend on numcodecs for zstd in that library?

[d-v-b]

the context is, putting codec implementations in a separate library only makes sense when they require special dependencies. If a zstd codec can be implemented in zarr-python directly via simple dependencies (like a backport), then we don't really need numcodecs in the loop for that codec

[avalentino]

I didn't look at the code yet but it seems reasonable to me.
I will try