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 impactdask-grblas (CC@ParticularMiner).

Final thoughts and future possibilities:

• We could allow default operators to work on array dtypes of normal dtypes (such asnp.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 asnp.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 standardregister_new andregister_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.