Refactor backends to separate writers from readers

[TomNicholas]

This refactor deals with a few related code structure issues:

• core/datatree_io.py exists totally separate from the rest of the backends code
• backends/api.py mixes code for opening data (which are truly part of the backend engines system) with code for saving data (which are not)
• backends/api.py contains code that is not actually part of the public API

My changes instead move all code that has to do with writing out into a new backends/writers.py file. This means we can delete core/datatree_io.py, and everything in new backends/api.py is now actually public API.

There should be no functional changes, I'm just moving things around to separate concerns and organise better.

I'm open to better suggestions for names for the writers.py file.

Note this refactor is arguably the first step of #5954.

[shoyer]

This looks great, thanks!

[shoyer]

Would it make sense to rename api.py now to readers.py or highlevel.py?

[TomNicholas]

Would it make sense to rename api.py now to readers.py or highlevel.py?

Maybe, but I actually kind of think api.py and writers.py should not be in the backends module at all. They call the code in backends, but they don't define the backends interface nor do they actually implement specific backends. In theory they should only really even use the public API defined in the rest of the backends module.

It would make more sense to me to only keep the code in the backends module that actually has to do with the backend registration system, and instead put the contents of api.py and writers.py into core/io/readers.py and core/io/writers.py or something like that.

But I was afraid of making such a drastic changes in this one PR in case it breaks things (potentially in external libraries that should not be importing these things, but probably are anyway), so I kept this PR to changes that I thought would be less likely to cause any issues.

cc'ing @max-sixty who I bet would have an opinion on this too 😄 (ref #10089)

[ianhi]

case it breaks things (potentially in external libraries that should not be importing these things, but probably are anyway),

An in-between is to make the change to make xarray have an improved layout, and keep api.py for a bit, importing everything from the other files with a very obnoxious warning that this is deprecated and going away soon.

[dcherian]

Nice!

[max-sixty]

looks great!

(no strong view on the api vs readers etc!)