Make CaloFutureCorrectionBase thread safe

This is a temporary patch to make CaloFutureCorrectionBase class E, S, L thread-safe. #82 (closed)

The Status.

All three classes (E, S and L corrections) share methods of the CorrectionBase class, however the method incidence() was used only by the E correction and only for the electron hypothesis. The incidence() method has been used to get the incidence angle of the reconstructed track pointing to the given cluster. To do this it called get -> match_tracking_tableLHCb::CaloFuture2Track::IClusTrTable-> relations CaloFuture2Track::IClusTrTable::Range -> track LHCB::Track

Then make a temporary ProtoParticle for this track and add it to the CaloHypo that is processed. Then a special toolLHCb::Calo::Interfaces::IElectron is used to get the incidence angle of the track. Finally a difference between the angle of the track and the angle obtained from the cluster only - dTheta.

All of the previous paragraph is now moved to ECorrection class.

dTheta is later used in one of the algorithms in the Base class, still, only for the purpose of correcting E.

The thread-unsafety was due to the getIfExists to get the 'match_tracking_table' inside of the correcting method while the table is already in ClassifyPhotonElectronAlg and this is the only algorithm that calls for ECorrection. (The other algorithm CaloFutureShowerOverlap calls only for S and L corrections).

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

The changes.

All corrections are called via the ICaloFutureHypoTool interface, explicitly the process (span) method. Temporarily to pass an extra argument I added an extra method correct that takes

[std::optional<std::reference_wrapper track_matching_relations = std::nullopt]

as a second argument. This is in fact a const& to the relations type with a default option 'std::nullopt'. Relations are obtained in the ClassifyPhotonEletronAlg but only to check if it is empty and decide to make a photon or electron hypothesis. Now, in case of the electron the reference to this relation is passed to the correcting methods.

Moreover I explicitly defined the apply pointer function that previously was made as a template but it was using always the same type of arguments. Here these are fixed. I commented out the checks that use get() in ClassifyPhotonElectronAlg. They are not thread-safe. The counters used there won't match for the moment obviously.

========================================================================= Summary. This construction is overdoing a lot. I plan to work during the hackathon on simplifying the correction algorithms to check if we really need to pass this relation table. Even if do need this, pass it only for the E-correction for electron hypothesis.