Writeable backends via entrypoints

The backend refactor has gone a long way towards making it easier to implement custom backend readers via entry points. However, it is still not clear how to implement a writeable backend from a third party package as an entry point. Some of the reasons for this are:

• While our reading function (open_dataset) has a generic name, our writing functions (Dataset.to_netcdf / Dataset.to_zarr) are still format specific. (Related to https://github.com/pydata/xarray/issues/3638). I propose we introduce a generic Dataset.to method and deprecate the others.
• The BackendEntrypoint base class does not have a writing method, just open_dataset:
  https://github.com/pydata/xarray/blob/e0deb9cf0a5cd5c9e3db033fd13f075added9c1e/xarray/backends/common.py#L356-L370
  (Related to https://github.com/pydata/xarray/issues/1970)
• As a result, writing is implemented ad-hoc for each backend.
• This makes it impossible for a third-party package to to implement writing.

We should fix this situation! Here are the steps I would take.

• Decide on the desired API for writeable backends.
• Formalize this in the BackendEntrypoint base class.
• Refactor the existing writeable backends (netcdf4-python, h5netcdf, scipy, Zarr) to use this API
• Maybe deprecate to_zarr and to_netcdf (or at least refactor to make a shallow call to a generic method)
• Encourage third party implementors to try it (e.g. TileDB)

Start with the BackendEntrypoint base class in xarray/backends/common.py and compare its open_dataset entry point with the existing Dataset.to_netcdf and Dataset.to_zarr paths. The issue is complete only after a writing API is decided, formalized, applied to the netcdf4-python, h5netcdf, scipy, and Zarr backends, and its third-party usability is considered.