Bypass: Extract common code for postcoh and bypass pads

Depends on !117 (merged)

This is a bit of a larger refactor, it Might be too much for the initial check in (or best done in stages like with flag_segments), but I think it's necessary for bypass to go in.

It renames a bunch of variables from data to postcoh_pad/bypass_pad/snr_pad/collect_data. The types of those variables are all related. postoch_pad & bypass_pad effectively inherit from GstCollectData (as before). I've called them *_pad instead of *_collect_data because I think the former is clearer. It's a Bit of a misnomer, since these aren't GstPads, but it's all their members and such. In context, I think it reads much better.

I've also pulled 'snr_pad' out as the sorta overlap between postcoh_pad and bypass_pad. The idea is that, if there's common code between postcoh & bypass, they can each call a function that takes an 'snr_pad' instead. I've not yet hit a function that requires it, but I have done a similar change using a 'GstCollectData' that they both inherit from.

'snr_pad' had a superset of what postcoh needed, so in effect I'm getting postcoh to record a bit of redundant & unused data, but it should be trivially small, and Technically correct anyway.

There may be some more fields that are best pulled in/extracted as more functions are refactored.

For now I'm shoving all the common code in one file, though it's pretty quick and easy to pull those out to new/discrete files/classes, just gotta carry on with the refactor to get a good picture of how to divide things up.

Testing

I've built & done a run here: /fred/oz016/tdavies/projects/testing/run_tdavies__add_inheritance_to_pads, and verified it gives identical zerolags to .../run_tdavies__extract_flag_segment_type, but that's just a regression test. It doesn't use bypass.