Change behavior of param and param selection merging

What is the change?

With this PR, we are introducing a new change in how Mindmeld deals with params and _paramselection in model configuration files.

What was the earlier behaviour?

If there was any configuration that was provided in the config file for a Mindmeld application, we would completely ignore the default configuration.
If we have both params and _paramselection in a config, we would run the param selection on the specified params and ignore the values in params.

What is the new behaviour?

If there was any configuration that was provided in the config file for a Mindmeld application, we now merge the params of the Mindmeld default and the user-defined config. (Conflicting params are overridden in favor of the user-defined config)
If we have both params and param_selection in a config, we run the cross-validation grid on the values specified in _paramselection and choose the best model parameters while also including the values in params fixed during selection. If we have any values that are common in both params and _paramselection, we inform the user of the conflict, and proceed with running param selection on that value.

Why are we doing this?

This change is introduced to for two main reasons: 1) In order to help facilitate the update process for scikit-learn, we need to eventually change the default solver for our text and tagger models. In order to make sure this change can be applied everywhere uniformly, it makes sense that we have it stored in our default configurations. This change also allows us to easily adapt to new configuration changes from the scikit-learn side of things with minimal code overhead for us. 2) The behavior of _paramselection when we also have params defined seems unintuitive. A user that defines a value in params is sure of it, and would want that value to be reflected across the model and expects a _paramselection across the range of values defined while also making sure these are the best params we can get with the fixed params values included. This new change implements this behavior.

Something I discussed with @vrdn-23 :

How about we get rid of the two configs and the need to merge them, and instead provide the developers with a single config that has tunable/fixed parameters and a boolean flag that determines whether grid search needs to be run; with each parameter only having one definition in the config rather than possibly having two as in the current implementation.

Something like:

params = {
   "penalty": "l2", 
   "C": 100, 
   "solver": "liblinear",
   "run_selection": False,
   ...
}

params = {
   "penalty": ["l1", "l2"],
   "C": [10,100,1000], 
   "solver": "liblinear",
   "run_selection": True,
   ...
}

This could be a design change t prevent developers from specifying the same parameters in both the static and variable parameter selection that could cause confusion; and also prevents the whole error/warning message feedback for the developers to fix this error.

cisco / mindmeld