[SPARK-4789] [mllib] Standardize ML Prediction APIs

This is part (1) of the updates from the WIP PR in [https://github.com/apache/spark/pull/3427]

Abstract classes for learning algorithms:
* Classifier
* Regressor
* Predictor

Traits for learning algorithms
* ProbabilisticClassificationModel

Concrete classes: learning algorithms
* LinearRegression
* LogisticRegression (updated to use new abstract classes)

Concrete classes: other
* LabeledPoint (adding weight to the old LabeledPoint)

Other updates:
* Modified ParamMap to sort parameters in toString

Test Suites:
* LabeledPointSuite
* LinearRegressionSuite
* LogisticRegressionSuite
* + Java versions of above suites

CC: @mengxr  @etrain  @shivaram 

I mean the former. Yeah, that's probably the downside. Each data element is at least an object, and you can't have it reduce to a `double[]` under the hood.

In the second example, I think you'd only ever really want `MixedFeatures` as an abstraction. There's no need to think of all `CategoricalFeatures` as a special case deserving a unique abstraction.

I suppose if you abstract the entire training example as an object, and allow accessors like `getNumericFeature(index: Int)`, `getCategoricalFeature(index: Int)` you can still internally optimize the storage while exposing a richer object representation. You get the type safety and optimization opportunity.

Sure, an `Array[Double]` could easily be translated into one of the more elaborate representations above. I suppose I myself wouldn't want to make it _too_ easy to not think about types!

Anyway, up to your judgment really. There are arguments several ways here. Worth a thought to see if the idea of a bit more abstraction appeals to you.