Distinguish between Global and Local Timeframe

This MR is a proof-of-concept for providing a more stable reference system for time measurements. Essentially it is the outcome of @pschutze's suggestions in the discussion of ticket #136 (closed) and implements time as proper fourth dimension, meaning we introduce a global and local reference system and carry information for both systems with the objects. Below text is quoted from the ticket.

This MR introduces the following changes/definitions:

• the global time reference frame starts with beginning of the event, i.e. start of particle tracking
• the local time reference frame for each sensor starts with the entry of the primary particle. Secondary particles inherit their local time frame from the parent. This would mean that e.g. the primary Proton has a local time of 0, while a delta ray produced has a local time of a few picoseconds, i.e. the time between entry of the proton and creation of the delta electron. The cool thing is that we can implement this directly in the setParent() method of the MCParticle object and don't need changes to the deposition modules.
• Pulses et cetera are always calculated in local coordinates, i.e. also in local time. This means, the integration_time parameters of many modules are as well interpreted in local time - which is essentially what we do already.
• All relevant objects are amended with functions getLocalTime() and getGlobalTime() to allow retrieval of the relevant information.

ToDo

• One corner case that is not easily solved (or not very logical in my mind) is the arrival of multiple primary particles with a time offset. Each of them will have a different local time in the same sensor, which might lead to odd results. One option would be to take care (where possible) in the deposition modules, to always take the first primary particle as reference, and not just the parent. The obvious downside of this is that the calculation cannot be contained within the MCParticle object (as it is now) but needs to be implemented in the modules and we have to remove the current (automatic) calculation from the parent.
• Another open question is how we want to carry time information from PropagatedCharge to PixelHit because currently PixelCharge does not carry any timing information. The local time definitely is undefined and needs since it just constitutes a bunch of charge carriers arriving at a pixel, so we cannot really define this. The global time we could in principle define as the time of the first PropagatedCharge of the object, but also that's not very physical. However, we do need global time information when we want to provide this information with the PixelHit object. The local time can be defined via threshold crossing, I guess that makes sense and is what is being done currently already in DefaultDigitizer (and soon in CSADigitizer). But the global time? In principle it should be the global time of threshold crossing but I'm not sure how to reassemble this information from the available.

This fixes #136 (closed).