Add Tests for vector input

[jbusecke]

• Towards [BUG] Issue in grid_ufunc when original_arg is a dictionary #581
• Tests added
• Passes pre-commit run --all-files
• User visible changes (including notable bug fixes) are documented in whats-new.rst
• New functions/methods are listed in api.rst

---

Tom: Suggested code improvements to prevent lots of bugs like this occurring:

• Properly type hint all places where a vector could be passed,
• Use the typing module's @overload decorator to type hint functions in an unambiguous way (i.e. scalar->scalar & vector->vector, but not vector->scalar),
• Type hinting pad and its internals is the most important part, because that's the only place that vectors are treated meaningfully differently,
• Other cases could potentially be handled by a @handle_vectors decorator wrapping methods, that unpacks, calls method, then re-wraps.
• Test padding dask arrays in functions like diff_vector_2d,
• Add an is_vector flag to any test dataset factory created (see #[FEATURE] Major refactor of the test suite #466 (comment))

[jbusecke]

Added a test to check functionality with vector input.

This exposed another (but perhaps related bug) to #581:
From what I can see the vector dict is passed to _pad_basic as is, which should never happen.
Digging into the pad function now.

[jbusecke]

Actually I think this bug is distinct (it happens inside the pad function, while the original bug occured in _rechunk_to_merge_in_boundary_chunks which happens after padding) from #581, but both are related to the vector syntax.
Trying to add a test that reproduces #581 first, before digging into pad.

Also I am not sure what the best testing strategy is here.

I think we need to parameterize the input (vector, non-vector) at least in a couple of places:

• For all padding option on the stand-alone tests for padding
• In the grid ufuncs tests, but do we need this for all of the tests?