Add unix_ts_usec to charge/events

[mjkramer]

The unix_ts_usec field is intended to provide a reasonably robust/precise timestamp (to within a few ms) for Mx2 matching. It is calculated by taking the LArPix timestamps and applying a correction for the slowly-drifting offset between the PPS and the GPS clock. This offset is measured by the new PPSDelayExtractor class.

[mjkramer]

The real money plot will be the one that shows good track matching performance in the CAFs, and I'm still working on that. But here's a plot that shows the extracted PPS delays from the first sandbox file (IO group 7 apparently had a unsynced system clock at the time; this is why we take the median of the measured delays across all IO groups!):

And here's what the charge/events dataset looks like at the end of the day. You can see the expected 0.2 s shift (relative to ts_start) in the new unix_ts_usec

[mjkramer]

And here's the money plot (using a 5ms trigger-matching tolerance in the CAF maker):

This is consistent with what the distribution of Mx2/2x2 track displacements used to look like, back when we only were including beam events in the 2x2 data and didn't need much timing precision for trigger matching.

[mjkramer]

Merging this since it seems to perform as intended for the 2x2 sandbox data. For simulations and for FSD data, we can just leave the extraction/correction disabled. For 2x2 data outside the sandbox, there is a potential corner case that could arise when the PPS pulses and GPS ticks are "close" (as in, less than ~50 ms apart). That discussion continues in #198.