IPredictor and related parts hiding

[TomFinley]

We have a few types inside IPredictor.cs that are perhaps useful for internal infrastructure, but are not directly useful from the point of view of the IEstimator/ITransformer/MLContext public API.

machinelearning/src/Microsoft.ML.Core/Prediction/IPredictor.cs

Line 10 in 3e03fce

public enum PredictionKind

machinelearning/src/Microsoft.ML.Core/Prediction/IPredictor.cs

Line 31 in 3e03fce

public interface IPredictor

The thing that makes me the most nervous are things like IPredictorProducing and IDistPredictorProducing, which are definitely marker interfaaces that we don't want, but I would argue we don't really want any of this to be public.

machinelearning/src/Microsoft.ML.Core/Prediction/IPredictor.cs

Line 43 in 3e03fce

public interface IPredictorProducing<out TResult> : IPredictor

machinelearning/src/Microsoft.ML.Core/Prediction/IPredictor.cs

Line 67 in 3e03fce

public interface IDistPredictorProducing<out TResult, out TResultDistribution> : IPredictorProducing<TResult>

There are a significant number of side effects from this, including the hiding of many other APIs that we want hidden anyway, since anything that is part of the IEstimator/ITransformer/IDataView/MLConext idiom does not take an IPredictor (it produces things that implement that interface, but generally we do not use that interface). So this will be a driver for hiding many other things.

[TomFinley]

This is somewhat tied in with the issue also of #1307, and also #2378. In attempting to resolve this issue, I see usages IPredictorProducing and descendants that cannot be replaced so easily, because depending on the options or other situations the type of object cannot be determined at compile time, due to calibrators. Some binary classification predictors will produce a calibrated model or not (e.g., averaged perceptron), so since there is no real object relationship they produce one of these types. However this is little better than if they had just gone and produced object as they are marker interfaces. So pursuant to #1604 this will be resolved by making the estimators just return whatever predictor object they "naturally" produce, though that will be resolved via #2378.