Check data location, not size==n_face, in UxDataArray.to_geodataframe() and .integrate()

[Sevans711]

Closes #1616

Overview

Switches to using self._face_centered() instead of self.values.size == self.uxgrid.n_face, inside UxDataArray.to_geodataframe() and UxDataArray.integrate(). The comparison to self.uxgrid.n_face is brittle; it might get messed up by any grids which happen to have the same number of nodes as faces, or same number of edges as faces.

Entirely removes the ... == self.uxgrid.n_edge and ... == self.uxgrid.n_node checks, and rewrites corresponding error messages. Those checks were just being used to provide a different error message based on size-based guess of data location; ultimately the errors were all ValueErrors with different ways to say "data that is not face_centered is not yet supported".

Adds a comment inside the integrate() method suggesting that it should support integration of face_centered data regardless of the n_face dimension position. In the meantime, the method continues to only support integration where the n_face dimension is the last dimension. (Possibly related: #1461.)

Still draft PR because still need to add regression tests, as discussed in issue 1616.
EDIT: now ready for review. Added tests for UxDataArray.to_geodataframe() and UxDataArray.integrate() for a node-centered array on a grid with n_face==n_node==6 (with same structure as the grid mentioned here: #1616 (comment)). These tests confirm a ValueError must be raised in this case, because these methods are not yet supported. Currently on main, these tests silently incorrectly assume face-centered data and provide answers instead of crashing. A crash should be expected here, to prevent silently incorrect results. (Sidenote: should probably be NotImplementedError instead, but changing error types should not be part of this PR; see #1622 instead for further discussion about error types.)

PR Checklist

General

• An issue is linked created and linked
• Add appropriate labels
• Filled out Overview and Expected Usage (if applicable) sections

Testing

• Adequate tests are created if there is new functionality
• Tests cover all possible logical paths in your function
• Tests are not too basic (such as simply calling a function and nothing else)