Stokes I 3d frequency fix

[Cameron-Van-Eck]

This includes my reworking of the Stokes I fitting to re-scale the model parameters and uncertainties to a new reference frequency. There are 3 major changes:

• the renormalize_StokesI_model function has been brought back. This function analytically modifies the parameters and parameter uncertainties of a Stokes I model to a new reference frequency. The parameter changes are analytic and exact; the transformation of the uncertainties requires a first-order approximation that breaks down for large shifts in frequency. This approximation should be fine for pretty much any case of real data (unless there's huge frequency gaps, maybe?), especially for POSSUM.
• the rmsynth1d tool now automatically converts the Stokes I model to the same reference frequency as lambda^2_0. When the Rudnick and Cotton method is used (lambda^2_0 = 0), the reference frequency is left as-is and the polarization reference frequency is set to be equal to the polarization frequency.
• For the 3D tools, there is a new tool: rmtools_3DIrescale/RMtools3D/rescale_I_model_3D.py. This reads in the coefficient maps created by do_fitIcube along with the covariance matrix map (a new output of do_fitIcube) to translate the parameters and uncertainties. This tool provides 3 options: grabbing lambda^2_0 from an FDF cube and rescaling the corresponding frequency, rescalign to a user-supplied frequency, or rescaling to the mean reference frequency (i.e., getting rid of spatial variations in reference frequency).

I've confirmed that all of these tools generate the expected outputs. The POSSUM pipelines may need some adaptation to this: the Stokes I reference frequency is removed as an output of the 1D tools, so minor tweaks to the 1D pipeline to remove that; the 3D pipeline will need an extra module to perform the rescaling and create fractional polarization maps (with uncertainties?).

I'm not entirely happy with this solution, but I've spent too much time on this already. There's some changes that I think would improve things, but I don't want to spend more time on this now:

• the Stokes I fitting routine should expose the reference frequency as a possible parameter (currently it forces the mean of the input frequencies, but this should be the behaviour when the user doesn't specify otherwise).
• The 3D Stokes I fitting should have a single reference frequency for the whole cube -- currently it can take slightly different values at different positions, mandating a ref. frequency map rather than a FITS keyword. Lambda^2_0 is set per-cube in rmsynth3d, and stored as a keyword -- we should do the same with Stokes I reference frequency.
• The first-order approximation for the uncertaintly propagation seems to work sufficiently well, but I worry that it may be fragile to extreme/pathological cases. The more robust solution would be to re-fit the data using a forced reference frequency (and passing the re-scaled fit parameters as initial guesses for the re-fit?) in order to be confident in the uncertainties.

I'm not going to implement these things now -- I don't think anyone really cares about uncertainties in Stokes I models from RM-Tools. So far as the POSSUM pipelines go this solution should be "good enough", and until someone actually cares I'm not investing more effort.

I'll leave this PR for a few days in case anyone wants to comment/look into it, otherwise I'll merge it in, merge everything else, and release v1.4.

[ErikOsinga]

Do you have an estimate to quantify what a 'large shift in frequency' means for the uncertainty transformation when re-normalising the Stokes I model to a different frequency? Maybe we can add a warning log when x = new_reference_frequency / fitDict["reference_frequency_Hz"] is too large?

[Cameron-Van-Eck]

Based on my experimenting, the threshold for a "large shift" varies a bit depending on the complexity of the model, and the specific parameters. But I suppose we could put an approximate threshold at ~10% change in frequency, and put in a warning for users when past that threshold. I'll add that.