The trainer name types should follow the names used in the contexts

[sfilipi]

Now that, as part of #1798 the Options of the trainers are part of the API signature, and the name of the trainer type displays as part of it.

The API looks like this:

// Pipeline.
var pipeline = ml.Transforms.Text.FeaturizeText("SentimentText", "Features")
      .AppendCacheCheckpoint(ml)
      .Append(ml.BinaryClassification.Trainers.SymbolicStochasticGradientDescent(
     new SymSgdClassificationTrainer.Options
     {
         NumberOfThreads = 1
     }));

notice the discrepancy between the extension name, and the trainer type.
Align naming where possible. Don't abbreviate the names, at least.

.Append(ml.BinaryClassification.Trainers.SymbolicStochasticGradientDescent(
new SymSgdClassificationTrainer.Options

[TomFinley]

We should do this a number of places, like, for instance, I see we have the so-called PavCalibrator to refer to PAV calibration, which is a real thing. Also similarly we have SDCA, and other things exposed in our class names.

[wschin]

We also mix the uses of model names and algorithm names, for example, LogisticRegression and SdcaBinary. Maybe we should use AlgorithmName+ModelName as a trainer's name.

[abgoswam]

Fixed by PR #2903