Improve performance of DoocsUpdater

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.

Start by locating DoocsUpdater, DoocsTransferElement, and the updateLoop, then establish a profiler baseline such as with vTune. Investigate the locking scheme, the two updatedElement maps, updaterFunction calls, and functor versus virtual dispatch as separate experiments. Done means all proposed optimisations were tested and only changes with measurable gains and acceptable readability remain.