Fix ifo_id/cur_ifo usage with ifo_is_gap

Related to #89 (reopened as the renames is probably worth doing)

As in the issue above, we have 3 different 'ifo' indexes floating around.
ifo_id is based on IFOMap, and is recorded in postcoh state->write_ifo_mapping
cur_ifo is based on postcoh state->input_ifo_mapping, which is in IFOMap order but only based on which IFOs are actually enabled.
i or pad_id, when iterating through postcoh's pads in the order they were attached. This is the index for *_ifo_mapping.

cur_ifo_is_gap is of size MAX_NIFO, and inconsistently used both cur_ifo and i as an index. So if we did a LH run, for L, it may set with index 1 and read with index 0, for example.

I've changed it to use write_ifo_mapping. I think in general we should move to using the 'standard' order where we don't care about storing a field per Available IFO.

I've also done refactors related to early variable declarations. To find the changes that are the actual purpose of the MR, search for ifo_is_gap.

Tests

I've done a test run here: /fred/oz016/tdavies/projects/testing/run_tdavies__fix_ifo_is_gap_usage I've only quickly compared the 013/zerolag file to a run branched from snr_series (so it has the same end_time_sngl initialization): /fred/oz016/tdavies/projects/testing/run_tdavies__extract_flag_segment_type/run1

Really this should be tested with non-sequential IFOs and IFOs in reverse order, on data that includes significant gaps. Although it seems like we likely have more issues.