Allow users to add track user information to G4 tracks, which then moves to Geant4Particle for saving

If we do not already store particles that become important'ish later we get a fatal error because the equilavent finding might not be able to find this particle

This logic only incurs a runtime overhead of two if checks if no particles are ever suspended.
Store non-primary particles that are suspended in a different map to pick their initial information up later again.

ParticleHandler: account for modified stacking actions, were tracking of a particle could be paused and later restarted.

Pick up the particle information that we have stored and go on from there

Improve the CMS example. Add word for the raw generator status of generator particles to Geant4Particle

if the hit is produced by a particle that is not kept in the MCParticle history we set the bit
added originalG4ID to Geant4Particle class for faster lookup, as this ID is stored with the hit
Otherwise we need a complicated and time-consuming logic to parse the equivalent map if this hit really belonged to that track

Add test to dump hits from MultiSegment-MultiCollections example. Investigate issue: https://github.com/AIDASoft/DD4hep/issues/141 for details

The G4event primary map does not know about the final state particles,
apparently. Need to find the G4Primaries we know about in the primaryMap and
look the the corresponding TrackID that was updated inside Geant4

need to compare vertex of particle (vsXYZ) with endpoint of parent (veXYZ)

avoid magic numbers :)

Moved LEFT_DETECTOR and PARTICLE_STOPPED

remove clearing of status (no longer necessary)

Fix typo in docstring
Geant4ParticleHandle: add printout of status bits in dump4

Fix hundreds of std=c++11 compiler warningsAllow to change compiler settings in cmake/DD4hep.cmake valid for all packages.Watch out for CMAKE_CXX_FLAGS in cmake/DD4hep.cmake.Move to use Boost spirit::phoenix version 3. ---- Prepare for ROOT 6