PPS delay edge case

[mjkramer]

This extends #195 to adds some logic for the case when the PPS is "close" to the GPS. In such situations, near the GPS tick, the LArPix timestamps could potentially be both "close to 1E7" and "close to zero", which could throw off the calculation of the median. We detect such a situation by looking for a large spread around the median, in which case we just set a PPS delay zero.

Here's what I get from a file where PPS and GPS were reasonably aligned:

Here IOG 1's PPS looks like it's 50ms "behind" the GPS tick whereas the other IO groups are actually 50ms "ahead" (or 950ms "behind") the GPS tick. Some, but not all of the delay measurements (one per IOG per second, generally) trigger this logic (leading to the large population of zeros). The median PPS delay for each IO group (as written to the file and used downstream to calculate unix_ts_usec) looks like this:

Although IOG 8 looks like a stark outlier, "930ms ahead" is the same as "70ms behind", which is close to "zero delay" (and close to IOG's measurement of "55ms ahead").

I need to think a bit more about what happens with IOG 8 the LArPix timestamps are < 50 ms.