New API and choice of units backends

[nstarman]

Currently the unxt package vendors a custom Quantity (and related) object as well as a UnitSystem (and related). The actual units and their conversions are managed by Astropy. To make unxt a tool for the general ML community it would be ideal to allow the user to choose what units backend to use.

This will require a fair bit of refactoring to decouple unxt from astropy.units. Instead of directly calling astropy functions we will need to develop more generic functions which can then refer to the chosen backend. I think we should lean into multiple dispatch and therefore draw inspiration from Unitful.jl. I'm envisioning

Dimensions-related API:

• AbstractDimensions: a non-init'able base class for all backends to subclass.
  • AstropyDimensions: wrapper around astropy.units.PhysicalType
  • ...
• [x] dimensions: function to create an AbstractDimensions object. like np.array for making np.ndarray. This is multi-dispatched for all the different ways to make a Dimensions object. (#181)
• [x] dimensions_of: function to get the dimensions of an object, returning dimensionless if it's not a dimensionful object. (#177)

Dimensions-system-related API:

• DimensionSystem
• dimensionsystem: function to create an AbstractDimensionsSystem object, making a new subclass if necessary.
• dimensionsystem_of: function to get / infer the dimension system of an object.

Units-related API:

• AbstractUnits: a non-init'able base class for all backends to subclass. This is a composite units object. Users will never see a lonely singular unit. This ensure that the API is the same, regardless of the backend.
  • attribute: dimensions
• AstropyUnits: wrapper around astropy.units.CompositeUnit
• ...
• [x] units: function to create an AbstractUnits object. This is multi-dispatched for all the different ways to make a Units object. (#175)
• [x] units_of: function to get the units of an object, returning dimensionless if it's not a dimensionful object. (#175)

UnitSystem-related API:

• [x] AbstractUnitSystem
• [x] specific subclasses, e.g. LTMUnitSystem for a length-time-mass only system
• [x] unitsystem: function to create an AbstractDimensionsSystem object, making a new subclass if necessary.
• [x] unitystem_of: function to get / infer the dimension system of an object. (#170)

Quantity-related API:

• [x] AbstractQuantity: base class
  • [x] field .value: Any
  • [x] field .unit: AbstractUnits
• [x] AbstractParametricQuantity, Quantity, UncheckedQuantity, AbstractDistance, Distance, Parallax, DistanceModulus
• [x] uconvert: the same API as Unitful.jl for doing a quantity's unit conversions. (#186)
• [x] ustrip: the same API as Unitful.jl. (#186)
• [ ] upreferred: the same API as Unitful.jl.

Support other plum API.

• [x] convert: this enables conversion to/from Astropy quantity. We can easily set up interoperability with Pint, unyt.
• [x] promote : this is used to enable Q subclasses to interact, e.g. a coordinax.Distance * a unxt.Quantity promotes to a Quantity.

Planned backend support:

• [x] Astropy
• [ ] Unyt
• [ ] Pint
• [ ] Julia's Unitful through e.g. JuliaCall
• [ ] Custom

[nstarman]

The new API is complete 🎉. What remains is good for a v2, where we offer choices of backends beyond Astropy. Users should see minimal changes, only a new Dimension and Unit object, which wrap the backend and provide improved features like array * unit = unxt.Quantity, not astropy.Quantity.