Xgboost 4j and Predictor implementations in separate sbt subprojects

[lucagiovagnoli]

This is a diff over combust#645

Main observation

I think the original solution at combust#645 is less disrupting to most people who don’t want to know about Predictor. Everyone will by default keep using xgboost4j. The solution in this PR brings a non-deterministic deserialization behaviour if users import both MLeap subprojects xgboost-runtime and xgboost-predictor.

Why? The “xgboost.classifier” key in the BundleRegistry contains either one of the Ops. I think this depends on how maven merges the reference.conf files via the “AppendTransformer”. This might be non-deterministic, similarly to how maven handles dependency conflicts? Secondly it also randomly depends on the scala hash key when filling up the BundleRegistry hash table.

Other observations

• The mleap-xgboost-predictor needs a sbt dependency on mleap-xgboost-runtime because it's using the testing helpers code from there. I am not sure sharing the testing helpers justified creating a third common project.
• I can't deserialize using both projects without tweaking the Bundle Registry. I had to remove the test "A deserialized XGBoost4j has the same results of a deserialized Predictor".
• Since I cannot serialize using the Predictor (store() is not implemented) I added static model files in resources that were serialized via the runtime project.