Static data design issues

Previously, the concept of Model was considered as a class instance representing a mathematical model with a set of free parameters being fitted. The library was providing routines to fit the free parameters set within a graph of variants. In this consideration, the model's data was not restricted by the free parameters set. Information like the function being fitted (Moyal, N-pole, template), various annotations (template type, number of max sample, required by p348reco, etc) was the subject of class itself, opaque from graph-steering routines.

At some point, however, it turned to be necessary to manage also the static data (all the data invariant with respect to free parameters). This way, the model type gets completely defined by set of free parameters and the static data.

I started to implement this, but made a rather unfortunate choice of setting different static data type for model and model view. As a result, an issue appeared when, during clone() <- assign_from() of the model view (that should result in a model copy, not a model view copy), we have to cast iParametricModel<ModelFeaturesT, WFTemplatesSD> to iParametricModel<ModelFeaturesT, WFTemplatesViewSD>.

At this point, one have to make a choice: either to introduce runtime checks and during assigh_from() handle a special case, or to change the design and clamp individual term model's static data to be the same type for both view and model. The second option is more favorable in many aspects, except for the fact that static data has to be copied each time the steering routines clone()s model variant, leading to some performance loss. At the other hand, this approach is less error-prone, since user code is not obliged to manage complicated relations b/w model's static data and model view's static data. Most of the time both are the copies of same data, while failing to do so will break key assumption of independent graph nodes.