Segregate "scoring" ML.NET components/NuGet packages so the scoring components evolve autonomously from the rest of ML.NET

[CESARDELATORRE]

Segregate "scoring" ML.NET components/NuGet packages so the scoring components evolve autonomously from the rest of ML.NET.

This will be a breaking change, although easy to fix in the apps when having the breaking changes.

If we segregate the scoring area of ML,NET, that would help when providing support to:

• UWP
• Unity
• ARM

So initially, only the "scoring" area of ML.NET could be supported in those environments. It would be less expensive than providing support to UWP, Unity and ARM to the whole ML.NET.
And in most scenarios, for those environments, the customer just want to score a model, not to train a model in an UWP app, Unity app or ARM app (Xamarin mobile app or IoT).

Related issues:
#1886
#1736
#22
#2252
https://xamlbrewer.wordpress.com/2019/01/25/machine-learning-with-ml-net-in-uwp-clustering/

[JRAlexander]

This.

[eerhardt]

The gains you'd get here aren't as big as you first think. If you have any "transforms" in your pipeline, you still need to run them at "scoring" time. And also, the output objects of the "training" code (basically the ModelParameter classes plus the transforms) are also needed at "scoring" time.

In all actuality, the only code you could eliminate at scoring time is the few classes that do the actual training - which wouldn't be a lot of code.

Looking at the above issues, they would all still remain even if we split the "trainer" code into separate assemblies. Reflection.Emit is used by "scoring". MEF is used by the custom transforms. etc.

/cc @TomFinley