Add more Dataset methods/properties to uxarray.Grid

[Sevans711]

Proposed new feature or change:

uxarray.Grid objects behave mostly like xarray.Datasets, but with some additional fancier behavior related to unstructured grids. They even display similarly to how Dataset objects display! So, I have come to expect/want all relevant Dataset-like behaviors to apply to Grids, too.

Examples of code I expected to work on Grids which currently does not work:

1. grid.get("node_lon"), grid.keys() and other dict-like behaviors
2. grid.identical(other_grid)
3. grid.nbytes (relevant: ASV better memory benchmarks #1609 (comment)) as well as other attributes like grid.coords, grid.data_vars, grid.dtypes
4. grid.compute() and other dask-related methods, in case some of the underlying data is chunked

Examples of code which should maybe work on Grids but which currently does not work:

5. grid.roll(n_node=10) -- I would think this should probably roll along the n_node dimension and maybe renumber nodes as needed? But, it's a bit ambiguous.
6. grid.rename(extra_var='newname') -- should probably return a new grid with extra_var renamed accordingly, if it isn't one of the core names for grids (like "node_lon" or "n_face"). This assumes Grid objects continue to support extra variables when present (e.g. when the input file contains non-grid-data, maybe something like "custom_node_labels" containing string labels for each node, in a small grid).
7. grid.isnull() could probably be allowed?

Examples of code which should continue to not be supported on Grids:

8. grid.mean() as well as min, max, std, and other statistics which don't really make sense to apply to a Grid
9. grid.interp(...) probably wouldn't really make sense
10. grid.integrate() and any other math functions which don't really make sense to apply across all data variables within a Grid

A 100% complete solution to this issue would require considering every single method and attribute supported by xarray.Dataset, deciding whether they should be supported by Grid, and implementing if needed.

That would probably be way too much to review within a single PR. On the other hand, it could get unwieldy to handle too many tiny PRs each implementing only a single new method or attribute, especially when the implementations are as simple as simply calling the corresponding method from the underlying grid._ds. My suggestion would be to instead create a few PRs which each form reasonably-natural groupings. For example, one PR might try something like "implements dict-like behaviors for Grids: get(), keys(), items(), ..." while another might do "adds Dataset-like attributes for Grids: nbytes, coords, data_vars, chunks, dtypes, ...". Each of them would address part of this issue. Comments in thread on this issue could be used to track a more exhaustive list of available Dataset methods and discussion about whether they should be implemented for Grid.