Update G4Atlas code to be consistent with Geant4 internal behaviour w.r.t G4TrackStatus

Geant4 Tracking keeps going as long the track status is either fAlive or fStoppedButAlive. See https://gitlab.cern.ch/atlas-simulation-team/geant4/-/blob/master/source/tracking/src/G4TrackingManager.cc#L131

The track status becomes fStoppedButAlive when the corresponding particle has at-rest processes but otherwise its tracking has already reached the end. For example when the kinetic energy of an e+ goes to zero, i.e. stopped, but it can annihilate at rest. In such cases, Geant4 performs that extra step in which the at-rest processes will be invoked. Then tracking is terminated as the status of the particle will be neither fAlive nor fStoppedButAlive, but fStopAndKill.

Some (but not all) parts of the G4Atlas code were checking for fAlive only, this has now been fixed. This should fix ATLPHYSVAL-1036.

In addition the ISFTrajectory class has been updated to throw a fatal G4Exception if we attempt to make a TruthIncident out of a GenParticle which already has an end vertex. TruthSvc and InputConverter will also now throw errors if they encounter this situation.