Interoperability with other units packages / future merging? #8210

From a short discussion at the coordination meeting: there are quite a few units packages around, which implement basically the same functionality in different ways. Some things we may want to do (in rough order of increasing difficulty):

Interoperation

• Ensure the different packages interoperate at the most basic level: OurUnit(OtherUnit) and OurQuantity(OhterQuantity) work. For units, this may be as simple as trying OurUnit(str(OtherUnit)), while for quantities we perhaps can rely on having .unit attribute (EDIT: unyt uses units instead of unit) and some way to get the value (.value? Perhaps just __array__?). Alternatively, we might agree on some quantity-specific dunder method.
• Interoperate in more detail, such that, e.g., our_quantity * other_quantity "just works". And that one could, e.g., do SkyCoord(other_quantity, ...), with auto-conversion to astropy Quantity.
• Try to be so agnostic to specific quantity implementations that one could just one type or another (in, e.g., SkyCoord) and everything just works, with now all output being in the type of quantity one put in.

Mutual Improvements

• List strong and weak points of different unit packages.
• Copy missing implementations, or replace poor ones with better ones.

Merge implementations

• Determine whether we are so similar that we can just merge implementations?
• Move a common implementation upstream? Really, numpy or scipy should support quantities, and possibly python itself should support units (and float quantities?).

cc @ngoldbaum, @astrofrog, @adrn, @eteq

EDIT: for some earlier thoughts about interoperability and abstract base classes, see #3650.