feat: Bucket silicon raw hits in time

[kkauder]

Briefly, what does this PR introduce?

For longer time slices, hits for a cellId cannot be integrated throughout the "event". This PR creates a new hit when the time stamp falls out of all existing hits' [time, time+integration window].

• Are the time resolution (or integration) values correct?

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No.

Does this PR change default behavior?

Yes.

[github-actions]

Capybara summary for PR 1359

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake
• rec_dis_18x275_minQ2=1000_craterlake
• rec_dis_5x41_minQ2=0_craterlake
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-06-25T12:53-04:00 474b954}}

[veprbl]

I was thinking about a similar thing, but for calorimetry. I suppose, for MAPS tracking this would look more like histogramming in time, rather than this. Otherwise looks like a fine first prototype.

[kkauder]

I was thinking about a similar thing, but for calorimetry. I suppose, for MAPS tracking this would look more like histogramming in time, rather than this. Otherwise looks like a fine first prototype.

I'm planning to do a similar thing for all hits, using this as a template as far as it's appropriate.

[kkauder]

This PR should be ready to merge. Liaisons, please check I used the right values for resolution and integration window, and that the implementation makes some sense.