CHG: Account for dead and double-wide strips in MModuleDepthCalibration

[fhagemann]

Addressing #157

In this PR, I am proposing a convention for disabled strips, both (dead and double-wide).

How to define disabled strips in a CSV file

The format to describe disabled strips proposed here takes the form Det ID, Side, Disabled Strip, [Read-out via]:

0 h 31    => HV strip 31 on Detector with ID 0 is dead (not read out at all)
0 l 14 15 => LV strip 14 on Detector with ID 0 is shorted to LV strip 15, and read out via LV strip 15

I have added files for all COSI SMEX flight detectors to resource/calibration/COSISMEX/unit and a combined one based on all unit-level calibration files to resource/calibration/COSISMEX/payload.

Note that most of these have HV strip 31 disabled (due to being tested with a faulty NICEv1 board)

What is changing in MModuleDepthCalibration

The depth calibration assigns the X and Y position as the center of the strip. For double-wide strips, this used to place the hits wrongly in the center of the strip that was read out, instead of at the center of the double-wide strip.

With the changes in this PR, we are now assigning hits in double-wide strips to the center of the double-wide strip, and we are also doubling the uncertainty on that position to account for the doubled strip width.
We are also not attempting any depth reconstruction for dead strips.

Accounting for disabled strips is optional and can be omitted using a check button, or by passing either no file name at all or a CSV file name pointing to an empty file:

What about the DEE?

I would like to discuss the current format of defining double-wide strip and get it approved in this PR, before tackling the DEE (probably in a follow-up PR).

For the DEE, I envision replacing finding dead strips (currently done by checking which strips do not appear in the energy calibration file) with the dead strips in this file, and do some more accurate charge sharing in SubModuleChargeTransport for double-wide strips.

[fhagemann]

I have some code to account for disabled strips in the DEE, but it's based both on the code in this PR, and the code in draft PR #190 (that's still pending the hardware threshold files).
I would delay opening a PR until this and #190 are merged.

[fhagemann]

This is ready for review now.

[ckierans]

Looks good, Felix! I like the simplicity of the shorted strip handling.