Internalize concepts of IDataTransform/Loader/TransformTemplate.

[TomFinley]

Before we had the IEstimator/ITransformer/IDataView triad (see #581), we combined all three concepts inside IDataTransform. The initialization, the data, and the data model were all conflated. This was the source for years of constant confusion internally. We of course had to abandon the idea when we were trying to make an API. Here's the interface, for reference:

machinelearning/src/Microsoft.ML.Data/Data/IDataLoader.cs

Line 90 in 2e67134

public interface IDataTransform : IDataView, ICanSaveModel

Similarly, before we had IDataReaderEstimator/IDataReader/IDataView triad, we combined all three concepts inside IDataLoader.

machinelearning/src/Microsoft.ML.Data/Data/IDataLoader.cs

Line 53 in 2e67134

public interface IDataLoader : IDataView, ICanSaveModel

We also have the old concept of ITransformTemplate, which the ITransformer interface has likewise obviated.

We've introduced the new concepts over the course of the last half year or so, which is great, yet the artifacts of the old world remain. The interfaces should be made internal so people don't stumble into using them. Further, the objects used through ITransform and IDataView should (even when still backed by an IDataTransform object!) be hidden so it is not obvious these concepts are being conflated internally, even if "under the hood" there is just a small shim to present what is (internally) an IDataTransform as publicly an ITransformer/IDataView. (Always with the aim, of course, of having the architecture reflect the shape it presents as its public surface, but what we can refactor over some time we can at least hide now.)

[TomFinley]

One example of this that I ran across is the PredictionTransformerBase:

machinelearning/src/Microsoft.ML.Data/Scorers/PredictionTransformer.cs

Lines 38 to 40 in 46efb8e

	public abstract class PredictionTransformerBase<TModel, TScorer> : IPredictionTransformer<TModel>
	where TScorer : RowToRowScorerBase
	where TModel : class, IPredictor

This is a Transformer, which is fine, but it quite inappropriately takes as a generic parameter something that is TScorer : RowToRowScorerBase, which is something exposing the "old idioms." However there is no reason to make this detail of implementation public, but it must be as a generic parameter.

In this case, happily, it looks like making this a generic parameter was completely pointless, so it can just be removed and the base class of the scorer used directly (but internally!!) in the abstract base class. But it is at least an interesting example of how badly we started "mixing our metaphors" when the new idioms of #581 were being introduced.