[ENH] Consolidate quantile parameterized distributions in few classes

[fkiraly]

@FelixWick, @setoguchi-naoki, @Ram0nB I think we should consolidate the three curent quantile parameterized distribution (QPD) classes into a single one, and move the distribution logic in the quantile regressor in another QPD related class.

This idea is based on two observations:

• the quantile-to-distribution logic in current MultipleQuantileRegressor is one way to construct a QPD with arbitrary number of input quantile predictions/values. PR showing how this could look like here: [ENH] empirical quantile parameterized distribution #236
• the Johnson QPD taking lower, middle, upper quantile predictions/values, output by CyclicBoosting, are spread across three classes which seem a bit redundant. They are also being reworked in [ENH] update Johnson QPDistributions with bugfixes and vectorization (cyclic-boosting ver.1.4.0) #232, related to the cyclic_boosting 1.4.0 release.

I would suggest the following end state:

• the logic in MultipleQuantileRegressor moves into a QPD, to which we can later add different interpolation modes and basis functions.

• I would suggest replacing the three QPD_X distributions by a single class for Johnson QPD, QPD_Johnson, or similar. This can have a parameter bounding which can be "bounded", "unbounded", "semi", mapping onto the logic in the three current classes.

Do you have any thoughts about this suggestion? It might simplify the interface(s) of the connected regressors as well.

[FelixWick]

I think that makes sense.
Also, instead of importing the J-QPD implementation from Cyclic Boosting, we might consider to create an independent class directly here in the new QPD module. (I know I suggested differently before, but your description changed my mind.)

[fkiraly]

Also, instead of importing the J-QPD implementation from Cyclic Boosting, we might consider to create an independent class directly here in the new QPD module. (I know I suggested differently before, but your description changed my mind.)

I think the "optimal state" is either that, or a lightweight interface, as for instance to scipy with Poisson.

[fkiraly]

Done in #232