Move Common.set_backend() to TriangleBase.set_backend()

[genedan]

Per this comment:

#1082 (comment)

so these tests would be the first time we actually use set_backend on an estimator in the codebase. honestly not sure if it's something we should encourage, or even allow. many estimators have a xp attribute, which could conflict with a manually set backend during subsequent transforming or predicting.

imo we should just take out set_backend from common and put into base (i.e. remove it from estimators). it never made sense to have set_backend on an estimator.

[henrydingliu]

persisting relevant comment from a parallel discussion

If we move the method to base.py, we won't be able to set the backend on the fitted attributes since that depends on the estimator inheriting from Common

i'd want to align on what is the use for set_backend on an estimator. to me, an estimator should be backend agnostic. it takes whatever backend of the training or inference data. unfortunately sklearn doesn't provide a very relevant precedent for us. sklearn, based on my understanding, forces everything to numpy, which wouldn't work for us because it would mean massive memory spike during estimation for a sparse triangle.

so i think this is the question that would dictate our implementation decision. if a user fits an estimator with numpy triangle, and then wants to turn around and apply it to a sparse triangle. do we expect them to

• convert the original triangle to sparse, and refit
• use set_backend on the estimator
• use the estimator directly, we'll take care of the conversion in the background
  once we can decide on one expected behavior, we can throw in a deprecation warning when set_backend is used on a non-triangle.

[henrydingliu]

additionally, my intention would be to deprecate Common entirely. In its place, we'll have DevelopmentMixin, AdditiveMixin, along with the recently created DisposalMixin,

• the main motivation is to let zeta and ldf live separately, and not leak into places where it doesn't need to be (e.g. zeta in Development())
     - we'd also want independent calculations of full_triangle_ and full_expectation_ for each mixin (right now IncrementalAdditive and DisposalRate are doing some funky stuff for these two)
• these mixins would be inherited by TriangleBase and their respective transformers.
• pipe, set_backend, and _validate_assumptions would all migrate directly under TriangleBase.