ITSMFT: scaffolding for staggered digitization

[f3sch]

This adds the possibility to 'stagger' the ITS/MFT detector digitisation. Currently this is disabled and steered by the a flag in the DPLAlpideParam. The output e.g. Branch names, digits themselves does not change from before.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[sawenzel]

Could you please add few more information what this achieves? How and where is this useful?

[f3sch]

The basic idea, is that the digit output is per layer and not anymore in a flat array. Then one can define per layer differing readout frame lengths, biases and offsets. The final goal is to also adapt everything up to the tracking to handle different ROFs, which is needed for ITS3 but already in ITS2 maybe tested (actually this data has already been taken).

[sawenzel]

Ok. Fine from my side as long as it's optional and not affecting production.

[github-actions]

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.

[shahor02]

Looks nice! But I've probably misunderstood how the file I/O is organized.

[alibuild]

Error while checking build/O2/fullCI_slc9 for b46a878 at 2026-01-22 15:22:

No log files found

Full log here.

[f3sch]

@shahor02 I implemented your comments and I think it should be ready to merge :)

[shahor02]

@f3sch thanks, fine for me