Option A)
- NodeModel also implements (or returns via method) a PredictiveModel
  which offers load/save functionality as well as an applyToRow()
  method.
- benefit: only one and only one PredictorNode needed
- problem: only one and only one PredictorNode available - that is a 
  pure classify-this workflow does not show which type of model it is
  using.

Option B)
- NodeModel which has ModelPortOut allows to retrieve Predictive Model
  which enforces load/save functionality
- NodeModel which has ModelPortIn allows to load Predictive Model from
  predictor parameters.
- Benefit: different types of nodes for different types of models
- Benefit: several different nodes creating e.g. a decision tree can
  use the same predictor node

Option C)
- PredictorNode used LearnerNode and potentially all of it's internals
  to apply.
- PredictorNode uses same load functionality and, for instance, also
  load HiLite-Translator table even though it's not needed.
  
Option D)
We have two extended NodeModels, LearnerNodeModel and PredictorNodeModel, 
which simulate for now one ModelPort, either as out- or in-port. The model
itself is stored inside a so-called PredModel, which has methods to load and 
save itself in XML (e.g. extending the Config object).
The LearnerNodeModel provides one additional abstract method call getPredModel()
in order to retrieve the PredModel generated during execute. The 
PredictorNodeModel gets an additional argument, PredModel, passed during the
configure(DataTableSpec[],PredModel) and execute(DataTable[],PredModel) call
adapted from the original configure(.) and execute(.) method from NodeModel.
The configure will then evaluate the PredModel against the DataTableSpecs of the
data to predict. The execute() then uses the model to make the final prediction
and returns the new output data table.
This works fine until we pass an empty data table during execute to model also 
the number of model ports explicitly. The next step will be to have also
ModelPorts, ModelIn- and ModelOutPort, over which the PredModels are ´
transferred. This model ports can be differently modeled in the GUI and don't 
need to pass an DataTable wrapper.

The reason for different Predictor-Nodes are mostly the
dialogs: different functionality are needed (create winner-column only, create 
columns for each class (membership values), create regression about with
variance...) 

Passing the Model to both configure and execute is a bit odd, as they have to be
 the same? Also, the Dialog may need information from the model, so the 
 configure needs to at least remember the parts that it will need to set the 
 dialog, which is even odder. That way execute and configure stay the same and 
 if the model is outdated (or non-existend) they will simply fail. Easy. But it 
 is in our hands (via the abstract PredictorNodeModel) to make sure things are 
 always called in the right order - similar to the validate- 
 Settings/setSettings stuff?

Why not also have a setModel(PredMdl) in the PredictorNodeModel and make sure 
(via our abstract class) that this is called before configure (and execute, of 
course) are called?

Can we, in theory, have Nodes that are both, Predictor and Learner? I.e. they 
take a model and some data and create a new model? We could use that also to 
create universal nodes to prune a decision tree or a set of rules...?
  
Ideas/Motivations:
- load&save of models needs to be implemented anyway (also for the learner
  nodes!), hence some way to store and retrieve the models is needed.
- reusing this load/save-mechanism to "transport" models between the learner
  node and the predictor node seems useful.
 
