Forbid path-like DataTree child names #9490

[eshort0401]

• Closes Forbid path-like child names #9490
• Closes Using a forward slash in a node names of a DataTree causes a RecursionError #9978
• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst

Addresses #9490 and #9978 by forbidding the / character in DataTree child names.

1. DataTree node names are already checked using _validate_name from the treenode module. I therefore call this function inside the _check_children member function of TreeNode. This check ensures invalid children arguments are caught early in the DataTree constructor, and when the DataTree.children attribute is reset explicitly (see Set child nodes via DataTree.children #9441). I have also reworded the _validate_name error message slightly for consistency with _check_for_slashes_in_names (defined in the datatree module) which checks variable names. To illustrate, code like

   import xarray as xr
   ds = xr.Dataset({"a": xr.DataArray([1, 2, 3])})
   dt = xr.DataTree(dataset=ds, children={"x/y": xr.DataTree()})

   and

   import xarray as xr
   ds = xr.Dataset({"a": xr.DataArray([1, 2, 3])})
   dt = xr.DataTree(dataset=ds, children={"x": xr.DataTree()})
   dt.children = {"x/y": xr.DataTree()}

   will now both produce

   ValueError: Node name 'x/y' contains the '/' character. Nodes cannot have names containing '/' characters, as this would make path-like access to nodes ambiguous.
   

2. I have also added a call to _check_children on the input children mapping given to the DataTree constructor, before it is assigned and the setter function is called. This additional check ensures that if the user passes a bad children, a helpful error message is given before the shallow copy {name: child.copy() for name, child in children.items()} fails.
3. I have added a couple of lines to the DataTree.__init__ docstring to communicate that / characters are forbidden in both the name argument, and the keys of the children mapping argument.

Additional Notes

This PR follows after discussion with @TomNicholas in #11001. See also #9441 and #9477.

[eshort0401]

I've just realized this PR is very similar to @TomNicholas's PR #9492 from 2024, sorry! Happy to update authorship in the whats-new.rst if appropriate. Not sure why #9492 wasn't merged as a temporary fix for #9485.