PLA-10433: Generic typing on Learner and TrainingResult interfaces

[sfriedowitz]

The main changes are as follows:

• Make the learner interface a Learner[T] which trains on a trainingData: Seq[(Vector[Any], T)]. It is now type specific for the label type of data. This is accompanied by having MultiTaskLearner <: Learner[Vector[Any]].
• Make the training results TrainingResult[+T] where again the type parameter is the type of the label data.
• Make Model[+T] take as type parameter the type of labeled not. Previously, it was Model[+T <: PredictionResult[Any]] was parameterized by the type of prediction results instead of the labels, which added confusion to the interfaces IMO.
• Break apart the lolopy classes based on their learnings tasks. We now have a specific RandomForestRegressor, RandomForestClassifier, etc.... This was done to avoid having a highly parameterized interface presented to Python, which I suspect would have caused issues.

One concern I have about these changes is how to handle the generics for classification. Internal to trees, we use Splitter[Char] and Learner[Char] because we encode all classification data as type Char. However, the higher level classes still extend Learner[Any], such as ClassificationTree <: Learner[Any] and RandomForestClassifier <: Learner[Any]. This works as far as everything compiles, but it feels a bit odd insofar as "classification" is being performed on different label types throughout the package.

TODOS:

• We still should add a TrainingRow[T] interface to avoid passing around big tuples of Seq[(Vector[Any], T, Double)] in various places. This should be a separate PR.
• I'm not super familiar with the python release process. Do we need a version bump on that now, or only when we cut a Lolo release?
• Potentially look into splitting up some things like Bagger[T] and FeatureRotator[T] into task-specific classes, and trying to subsume shared functionality in helper functions rather than jamming it into the same generic class.

[bfolie]

I'm not super familiar with the python release process. Do we need a version bump on that now, or only when we cut a Lolo release?

Bump the lolopy version as part of this PR. Then when you cut the release on GitHub, it sees that the version has been bumped and pushes to PyPi

[sfriedowitz]

@bfolie I rebased this into a feature branch I just created.

[bfolie]

Other than the one comment about changing TrianingData[I, L] to TrainingData[L], this LGTM