Document approach to experimental API #3840

I think we should document a standard approach to using the zarr.experimental section of our API in our contributing guide. This would help me review PRs such as #3732. I imagine it would also help users to know what exactly what they're getting into when using functionality from zarr.experimental, beyond the statement of no promises from https://zarr.readthedocs.io/en/stable/user-guide/experimental/#experimental-features.

A straw-man proposal:

We strive to either promote or remove classes/functions in zarr.experimental within 6 months of their initial inclusion in the namespace. While in the experimental namespace, the behavior, signatures, etc. can change at any time without notice. We will aim to announce the removal/promotion in the release preceding the change via a FutureWarning.