Add "hit sequence" for reordering hits from the same track in a detector

[sethrj]

Currently the track-parallel implementation in Celeritas means that the computer-time ordering of hits does not correlate to the simulation-time ordering: different tracks can hit the same detector before they take their next step inside the detector. This is unexpected by Geant4 simulation codes.

A common paradigm for sensitive detectors is to assume that multiple hits in the same detector region are from the same track.
For example, the ATLAS muon spectrometer assumes that multiple hits to the detector, before changing material (weird?) or having a track status of fStopAndKill, mean that it's a single track with multiple consecutive hits. It only stores the nearest position/time/radius within that one track crossing of the volume.

I think in CMSSW I've seen some caching of hits/data based on the assumption of track-level serialization.

To get around this but without doing something massively expensive like storing all hits over the entire event and sorting by SD, I propose as a first step we:

• Enable an option on a per-detector basis to defer hits in that detector
• Return an additional flag for each track slot about whether to flush the detector
• For now we can hard-code deferring a hit sequence until the track dies or leaves that detector volume
• Store deferred hits on CPU in a map based on the Celeritas track ID (we could use a separate DetectorStepOutput instance and just have the map store the index in that instance? do we want a separate DSO for each track? or do we want a more compact data structure?)
• When the hit sequence is flushed we just call HitProcessor on each of the hits for that track, and set fStopAndKill for the last one in the sequence (or do we add another enum field for track status?)

CC @esseivaju