Simple calo correction

The changes consider the CaloCorrection classes. We were working on two topics:

1. CaloFutureCorrectionBase.
2. CaloFuture(E,S,L)Correction.

In (1) the old version each the getParams was called (usually by getCorrection method) a vector memory allocation was made. The m_params table contained a vector, where the fist argument was the function enum, the second the dimension of the parameter vector and then the parameters. The position of this vector was labelled by type of correction and the cell ID. In fact it is ID.area (outer, middle or inner) that matters for the corrections. As an output of getParams a pair of function (enum) and vector of parameters is returned. To build a vector of parameters out of m_params each time a new vector was allocated in memory.

Here, m_params is substituted by m_params2 that is filled only when the condDB is changed. It is know a lookup table returning a pair {func, vector_params} for given type and cellID. The memory for two base dimensions, type and id.area, is allocated in the CaloFutureCorrectionBase class constructor. The vectors of parameters are allocated when the m_params2 is filled. We use the fact that in the data from DB the size of these vectors is known and can preallocated with "reserve". During normal running condition there should be no more memory allocations with the use of m_params2. The benchmark tests show an improvement when looking at the two callers with VTune: CaloFutureShowerOverlapTool::process()

• master: 5.00% (time/samples)
• SingleCaloCorrection: 2.99% (time/samples)

CaloFutureSCorrection::calcSCorrection()

• master: 1.80% (time/samples)
• SingleCaloCorrection: 0.72% (time/samples)

One of the remaining issues is to adapt to the new format the checkParams() method. This method checks the data for internal consistency and gives warnings when there is something wrong. It also warns when an unexpected call appears, such as unknown correction type or unknown correction function. It has been partially replaced by checkParams2() but still some warnings do not appear in the tests of the new version

The other is a strange behaviour in the multi-threaded mode. The results depend on the order of corrections. This still needs to be examined.

==================================

In (2) the E, S and L correction classes were refactorised. In CaloFutureSCorrection the calcSCorrection method is replaced by calculateSCorrection that takes an input structure with all the needed input and returns an output structure. Moreover, two methods: updatePosition and UpdateCovariance were added. Similar changes were done in CaloFutureECorrection. Here the calcECorrection takes on structure as an input and returns one structure as output. Methods updateCovariance and updateEnergy were added to this class. In all 3 correction classes some unnecessary comments were removed and general clean up made.

Reference updates in Brunel!909 (merged) and Moore!315 (merged)