Gap handling

This MR resolves an issue with gstlal-calibration-1.5.6 that caused the calibration pipeline to run with a ~20 minute latency when run on shared memory on the DMT. It was caused by the handling of missing input data at pipeline startup in version 1.5.6. The handling of missing raw data was changed in order to fix a line subtraction issue documented in MR 16. One of the changes was that GStreamer's GAP flag was set to indicate when witness channels used in the line subtraction were missing. This caused no issues until testing began on on l1dmt3 (the low-latency testing pipeline). It turns out that when gaps are used to indicate inaccessible data in some channels at startup (a typical occurrence), any latency accrued during startup is retained for some reason. Under usual circumstances, the pipeline can catch up after it briefly falls behind at startup.

The fix here is to indicate missing raw data in witness channels with a "minimum input value" rather than a GAP flag. This minimum input value is already used to set a threshold for the magnitude of input data determining whether it can be used. It was originally implemented in O2 and set at 10^-35 to resolve an issue where numerical underflows were causing the pipeline to fall behind. Most data that fails this criteria is replaced with 0. The reason that this minimum value is used instead of 0 in this case is that we want to be able to distinguish cases where a witness channel is actually zero from cases where it is missing. I've tested this version of the code to see that it will reproduce the fix documented at the end of MR 16, and that it runs with normal latency on shared memory on l1dmt3.