GeezerVison

Whew!

Okay, I think this is pretty much done. Tests and coverage are as solid as I can reasonably make them.
Nevertheless, a PR this large and invasive is likely to have a bug or oversight or three.
I also don't know how it'll impact dask-grblas (CC @ParticularMiner).

Final thoughts and future possibilities:

• We could allow default operators to work on array dtypes of normal dtypes (such as np.dtype("(3,)uint8"))
  • For example, plus(A | A) could add subarrays together
  • This could also leverage normal NumPy broadcasting rules for the subarrays (i.e., numba's default)
• (in)equality checking of UDTs could probably be faster
  • array dtypes could probably be specialized
  • should be benchmarked to determine what is best
• NumPy string dtypes (such as np.dtype("S5")) are not tested (but I played around with them in my preliminary experiments)
• Should we require dtypes to be registered? Can things "just work" if given a numpy dtype?
  • In this PR, I kept to the standard register_new and register_anonymout pattern we use elsewhere.
• Ideally, we should document UDTs better in docstrings and online documentation. (We'll get there someday, but I'm wiped!)

This PR opens up a whole universe of possibilities. Record dtypes and array dtypes support different use cases, and both can be super-important.

Anyway, I think this PR should be merged ASAP, but feedback is welcome for any who are courageous enough to review it (CC @jim22k). Although I think things are pretty good, we can always smooth any rough edges we find once we actually implement workloads that needs UDTs.