Inconsistency between use of PCAL Corrections between GDS and CAL-CS

Cross-reference to IIET Ticket https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=12638

NOTE: THERE ARE THINGS THAT WOULD EFFECT THE GDS AND CALCS PIPELINES AS WELL AS PYDARM. PLEASE KEEP THE ABOVE TICKET, AND THE USERS CC'D THEREIN APPRAISED OF CHANGES TO THIS EFFECT.

When computing time-dependent correction factors, because the GDS pipeline picks up the PCAL channel for demodulation from the end station, and CAL-CS receives a version of the signal shipped from the end to corner (i.e. delayed by one fsample = 16384 Hz clock cycle => 61 usec), then the demodulated signal from each must be handled differently.

In March 2019, the pyDARM universe was changed to include this clock-cycle delay in its PCAL correction factor, such that when the PCAL channel stored in the frames is read out, it's read out as though it came from the corner station.

This was installed such that the reference model parameter values at calibration line frequencies (including this PCAL correction) can be the same for both the GDS and PCAL pipelines.

HOWEVER, the PCAL correction is used for many other purposes than just computing reference-model parameters for the computation of time-dependent correction factors. One example is processing sensing function and actuation function measurements, which use the frame channel for PCAL, and thus must correct for the usual PCAL corrections.

Of course, you want to use the same pcal correction everywhere in the pyDARM universe, but that means that the above mentioned artificial delay to bring the PCAL to the corner station is the wrong thing to do for processing actuation and sensing measurements.

Whatever we do -- this ticket is to make sure that we're consistently using the pcal correction everywhere, and it has all of the right components.