Reorder output ifo strings to match IFOMap order

This MR changes the previous logic used to set the self.ifos attribute of FinalSink. Now, we no longer use the lsctables function to order IFOs (which explicitly recommended to not use the function in question). Instead, we loop through the ifos listed in order in IFOMap, and concatenate them together if they are present in our channel dict.

As we iterate through as H1, L1, V1, K1 now instead of H1, K1, L1, V1, the output element/column orders will be changed accordingly, but our external data artifacts do not require that our ifos be written in any specific order as they can be retrieved by their string name.

Test Case

Following through where the self.ifos attribute is used in Finalsink reveals that this should only effect the output of the key-value pairs/columns of the output documents, such as our SegmentDocument or coinc.xml document. This is also passed to gstlal_cohfar_calc_fap, but the ifo_set__try_parse function in background_stats_utils.c#L69. should handle ifo strings of arbitrary order.

For a test, we should run a quick KAGRA run with an injection and examine the contents of all files output by the pipeline.

We should see no changes other than the expected behavior of element/column orders for ifos being changed in the output data.