Provide secondary vector in G4Step

[SeverinDiederichs]

Note: this PR depends on #487 and is therefore based on it, as otherwise merge conflicts would arise. Only to be reviewed after rebase when #487 is merged!

This PR introduces a secondary vector in the G4Step. Thus, SD codes or UserActions that rely on the secondary vector will now not find only a secondary vector, but the correct secondaries produced in that step.

After the reordering #486, this PR changes the following:

• The steps on the GPU are now recorded [parent1][secondary1,1] - [parent2][secondary2,1][secondary2,2] - [parent3]...
• the number of secondaries is returned in the step
• When looping over the returned steps and processing them, the parent steps directly consume the corresponding secondary steps
• The secondary steps are still just the initializing steps, so they setup the HostTrackData mapper.
• Before, the secondaries always had to query for the hostTrackData entry of the parent to get the G4 parent ID. As they are processed now together, the G4 parent ID can be directly passed, which reduces the expensive lookup and therefore accelerates the code
• Similarly as before, a persistent storage for the secondary tracks and also for the secondary vector is created, to avoid re-allocation. This made notable run time differences

For turning the userActions on, this PR slightly improves the run times over #487:

Example	PR 487	This PR
Em3 Regions	95.486	94.4245
Em3	116.413	110.233

It was verified that this PR

• Changes physics results
• Does not change physics results

[phsft-bot]

Can one of the admins verify this patch?