[BUG]: Using the `HMS_HMS_RLO` grid, breaks `calculate_formation_channels`

Describe the bug
When running a population with the HMS_HMS_RLO grid breaks the calculate_formation_channels, because the latter expects interp_class_HMS_HMS to be populated. Something similar can happen when the user doesn't output interp_class_HMS_HMS as an oneline column.

Expected behavior
The main history will have oRLO1 in it for a run with HMS_HMS_RLO which we can use in the formation channel. Or the user has to add interp_class_HMS_HMS_RLO as output and we have to adapt the formation channel calculation appropriately.
A normal run with the HMS_HMS grid will not have this outputted though..

In general, we should rethink the information outputted by the binary history related to mass transfer during the HMS-HMS and CO-HeMS grids (not RLO). Currently, we do not put an oRLO1 in the binary history if the interaction is stable. This gives the impression no interaction took place.

I think it would be more intuitive for the user if both unstable and stable mass transfer during the HMS-HMS grid outputs somethings like oRLO1 to indicate that the systems underwent mass transfer./

Start by tracing calculate_formation_channels and how interp_class_HMS_HMS, interp_class_HMS_HMS_RLO, and oRLO1 are populated in the HMS_HMS and HMS_HMS_RLO grids. Compare stable and unstable mass-transfer cases and decide how binary-history output should consistently represent them; done means formation-channel calculation works for both grids without requiring an optional output column.