Improve performance of DoocsUpdater

[mhier]

This is basically a follow-up of #14, but the scope goes beyond ZeroMQ and macro pulse numbers.

There are various points in which the DoocsUpdater could be optimised for performance:

• Locking scheme: filling locationsToLock requires a lot of cpu and involves even memory allocation.
• There are two maps with a map lookup for the updatedElement. This can be packed into a single map, so there is only one lookup.
• Avoid calls to updaterFunction() when possible: This can be achieved by moving the DataConsistencyGroup into DoocsTransferElement so it can be directly accessed in the DoocsUpdater::updateLoop(). If the DataConsistencyGroup says there is no consistent update to process, there is no need to call the updaterFunction().
• Maybe replacing the functor objects for the updaterFunction() with a virtual function call in DoocsTransferElement is more efficient?

DoD:

• Try out all of the above potential optimisations. Check if they improve something with a profiler (e..g vTune).
• Keep an optimisation unless it makes the performance worse, or it makes the code much more complicated / less readable and there is no gain.

[phako]

I have a tentative improvement for the first point lying around in my stash (I was annoyed by the two loops there); I will put up a PR, but I do not have any benchmarks