Simplify internals to prep for 1.0 release #601
Description
On the path towards 1.0 there are several refactors worth considering that would simplify the code base and bring it more into software development best practices.
Backend support
To migrate to an arrow backend, we should minimize existing backend support to just numpy/sparse.
cupy and dask were always elective and not well maintained. They add unnecessary complexity to the project and should be removed.
Clarify Triangle public API
The Estimators occasionally manipulate the private internals of the Triangle class. This makes the Estimator code heavily coupled to the internals of the Triangle making refactors of Triangle internals difficult. We need to force etimators to only use the public API. This may include adding additional support properties and methods to the Triangle class that the estimators can call on as opposed to direct manipulation of the underlying triangle structure.
kdims, vdims, odims, ddims
These are internal aliases for index, columns, origin, development. They exist to bypass some of the consistency checks on these axes. These certainly shouldn't be in the public API, but even internal to a Triangle, they are difficult to manage. They should be refactored out of the Triangle with no changes to the public API.
None of these should change any of the exiting public API of the package and all test should continue to pass.