Refactor waveform sampling

[wbenoit26]

This PR adds a parameter to waveform generation, coalescence_time (which I might re-name to signal_time to be more general), which takes the end of the generated waveform and rolls it to an arbitrary point in the timeseries (is it fair to assume that the end of the initial timeseries is the relevant time? This could be parameterized as well). This change is reflected in the way waveforms are loaded for training and validation.

Separately, I've removed the old trigger_pad parameter in favor of parameters that specify the distance of the coalescence point from each edge of the whitened kernel. This allows us to keep the coalescence point 0.25 seconds away from the left edge while also going all the way to the right edge. Again, this changes the way that waveforms are loaded.

@EthanMarx, I'm not sure that I've done this in the neatest way possible, so happy to take suggestions.

To-do:

• [x] Check that coalescence point falls where it should in training kernels
• [x] Check that coalescence point falls where it should in validation kernels
• [x] Determine why condor jobs aren't being submitted for inference
• [x] Decide whether new coalescence parameter should affect how foreground injection timings are calculated
• [x] Update pad_waveforms function and autoencoder sampling

Realized that the new way of loading waveforms makes the pad_waveforms function unnecessary, so I've removed it.

[EthanMarx]

Great to see this. Would be nice to see an end to end training run to confirm things are working right. Might be good to log on WandB (I should probably clean up all the garbage runs that exists there)

[wbenoit26]

Yeah, I've got one going, though it's going exceedingly slowly for some reason, so I'll probably restart and try again

[wbenoit26]

@EthanMarx I completed an end-to-end run, and the SV looks as expected

[EthanMarx]

@wbenoit26 Is this good to go?

[wbenoit26]

Yeah, I think this is all set unless you see anything else that needs to be changed.