An alternative implementation of a type for HGC/CALOROC output

[ruse-traveler]

Briefly, what does this PR introduce?

This PR introduces two types to facilitate work with the output of HGC/CALOROC chips:

1. The component, edm4eic::CALOROCSample, which defines for a given sample read out by the a chip
   • the ADC,
   • the Time of Arrival (TOA),
   • the Time over Threshold (TOT),
   • and the in-progress/complete relevant flags for TOT;
2. And the datatype, edm4eic::RawCALOROCHit, which consolidates for a given hit
   • the geometrical information (cell ID)
   • the time information (time stamp and sample phase),
   • and the relevant samples organized into a time series (represented as a vector member).

This PR is intended to supersede #101. It makes two distinct design choices from #101 informed by experience from the 2024 LFHCAL and EEEMCal test beams, both of which utilized HGCROC prototypes.

1. Rather than define separate vector members for the ADC, TOA, and TOT values, these values are collected into a component which are then stored as a vector. This more closely matches what the HGCROC actually reads out, where each value is technically read out once per sample (even if some, such as the TOA and TOT are zero for most).
2. The dual readout ("Type B") chips are intentionally not supported by this type. This is because such chips are currently not available nor in use. It is assumed that the processing of such a chip would be significantly different than the current chips actually in use ("Type A"), and as such would be better supported by a distinct type.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue Proposal for Waveform and Raw HGCROC Hit #89 )
• 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?

No.

[veprbl]

Thank you for addressing my comments, @ruse-traveler . This looks good to me. I have no further suggestions.

[tlprotzman]

This looks good to me as well. The only thing I'm not totally confident about is how the phase will actually be used, but I agree it is good to keep in the data type.