Changes related to multithreading

[lobis]

• Changes related to restG4 MT geant4lib#59
• Update reference root files in validation for PandaX framework#273

This PR introduces significant changes necessary to allow for multithreading to work. It also introduces some minor features that appeared naturally along the way.

README has also been updated with a description of some of these features.

restG4 has new cli options:

• -t to select the number of threads for multithreading
• -n to select the number of generator events (and override the value on the rml file)
• -e to select the "desired number of entries" so that the simulation will stop once this number of entries is achieved. In practise probably a few more entries will be saved on the file. The value of nEvents will be updated to the corresponding value of the number of simulated events.
• --time to set a maximum simulation time. As the previous option the simulation will stop if more than the set time has elapsed. The value passed to this flag looks like: 1h30m20s, 1m20s, 1h, 20s, etc.

Now the simulation can be stopped (via CTRL+C) and instead of crashing it will attempt to save results into disk, also updating the nEvents to the correct value.

All examples have been updated to the changes described in rest-for-physics/geant4lib#59 and a new example has been added to validate primary generators (anyone is welcome to write more checks in this example). As mentioned in the Geant4lib PR, RML files that use the old naming conventions (energyDist instead of energy etc.) should still work.

Now we are using Geant4 SteppingVerbose which allows to store the initial position of the track. This means a new hit type "Init" is saved for every track and means we can easily draw tracks. We don't need to find the last position of the previous track to draw the first point of the current track.

StackingAction is used to separate decays into subevents.

Logic has been simplified and methods such as EventAction::ReOrderTrackIds have been removed, which increases simulation speed.

After this PR multithreading should work (via the -t flag, such as restG4 -t 4 simulation.rml). Everything seems to work so far but the results have yet to be validated extensively. Using the same random seed with different number of threads will produce different results!

[juanangp]

I think we should re-visit the multithreading because I think that some variables should be defined as atomic. Also, I think the signal handler and the abort logic can be improved.
Anyhow, I think that this PR can be merged and we can do these changes later on, can you create an issue about that?