This PR continues the overall work of migrating DataTree into xarray.

• xarray/core/datatree_render.py is the renamed version of xarray/datatree_/datatree/render.py.
• xarray/core/extensions.py now contains functionality from xarray/datatree_/datatree/extensions.py.
• xarray/core/formatting.py now contains functionality from xarray/datatree_/datatree/formatting.py.
• xarray/tests/test_datatree.py now contains tests from xarray/datatree_/datatree/tests/test_dataset_api.py.
• xarray/testing/assertions.py now contains functionality from /xarray/datatree_/datatree/testing.py.

I had also meant to get to common.py and what's left of io.py, but I've got a hefty couple of days of meetings ahead, so I wanted to get this progress into PR before that happens. @flamingbear or I can follow up with the remaining things in a separate PR. (Also this PR is already getting a little big, so maybe it's already got enough in it)

• [x] Contributes to migration step for miscellaneous modules in #8572
• [ ] ~~Tests added~~
• [ ] ~~User visible changes (including notable bug fixes) are documented in whats-new.rst~~
• [ ] ~~New functions/methods are listed in api.rst~~

This PR continues the overall work of migrating DataTree into xarray.

datatree_mapping.py is the renamed version of mapping.py from the datatree repository.

• [x] Closes migration step for mapping.py #8572
• [ ] ~~Tests added~~
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] ~~New functions/methods are listed in api.rst~~

This PR continues the overall work of migrating DataTree into xarray.

iterators.py does not have direct tests. In discussions with @TomNicholas and @flamingbear, we concurred that other unit tests utilise this functionality.

• [x] Closes migration step for iterators.py #8572
• [ ] ~~Tests added~~
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] ~~New functions/methods are listed in api.rst~~

This PR migrates the datatree.py module to xarray/core/datatree.py, as part of the on-going effort to merge xarray-datatree into xarray itself.

Most of the changes are import path changes, and type-hints, but there is one minor change to the methods available on the DataTree class: to_array has been converted to to_dataarray, to align with the method on Dataset. (See conversation here)

This PR was initially published as a draft here.

• [x] Completes migration step for datatree/datatree.py https://github.com/pydata/xarray/issues/8572
• [x] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

What is your issue?

Working on migrating the datatree.py module into xarray/core revealed that the DatasetView class, which implements Dataset while disabling methods to mutate the object, breaks Liskov's substitution principle. The type for one of the overloads of DatasetView.__getitem__ is more general than the corresponding Dataset.__getitem__ signature (due to the use of Self in the Dataset signature).

```

In Dataset:

class Dataset(...): ... @overload def getitem(self, key: Iterable[Hashable]) -> Self: ... ```

The use of Self means that signature inherited from the superclass has a return type of DatasetView, but the DatasetView signature is overridden to have a return type of Dataset (the more generalised parent).

To avoid this, a couple of implementations were attempted:

• A class that tries to intercept the methods that mutate the Dataset using getattr. This does not catch the __setitem__ method, as it is a Magic Method, and those aren't affected by getattr.
• A Metaclass that can intercept Magic Methods, too. Implementation was inspired from here. I didn't get it to fully work, and eventually realised this was getting too complicated given the scope of the original problem.
• A mix-in for the mutating methods. I couldn't get this to work in the timescale agreed upon.
• Resorting back to ignoring the mypy errors for now, so we can proceed with the migration (given that there isn't a significant implementation concern identified from these type issues).

Also note, there is a tangentially-related known mypy error when a property setter accepts an argument of a different type to the property itself (https://github.com/python/mypy/issues/3004). This affects the assignment of Dataset objects to the DataTree.ds property. (Separate issue, but related)