Remove special treatment of DC in tfCorrection + fix load_TF_fromVNA

[jusack]

For inductive measurements the DC component gets lost, this would mean a real zero in the TF which can not be recovered.

At some point this has been handled by a keyword parameter tfDCCorrection, deciding if the TF should be applied to the DC components. This was changed to automatically detecting if all channels of the TF contain no zeros (or NaNs) and only then dividing by the TF-DC-value.

This leads to the following issues:

• If one TF channel has a zero in it (which would be the correct definition of the TF) the DC component does not get touched at all, meaning a DC offset that was numerically small in the V scale will be much bigger in the Am² scale the data is in after the correction resulting in a undefined behaviour
• One channel can deactivate the DC correction for other channels (e.g. channels that can actually detect DC and would need this correction)
• The workaround of just setting the DC component of the TF to a very high value to suppress the DC value leads to issues with the interpolation of the TF and, depending on the arbitrarily chosen value, to not so nice plots on a logarithmic scale if the DC component is orders of magnitude smaller than the noise floor of the measurement

Due to these reasons I want to propose just dropping the check for zeros in the TF all together as implemented in this PR. This results in the following:

• If the TF contains a zero (or NaN) the resulting value in frequency domain will be NaN, I tested plotting with CairoMakie (as used in MPIUI) and this value is just ignored in plotting. This is probably preferable to setting the value to zero, because the logarithmic scale breaks with a true zero
• For a time domain signal the DC component is set to from NaN to zero before inverse Fourier transform to have a time domain representation without any DC component

The only issue I could see with this is that a NaN value in the frequency domain data has to be set to zero manually if the user wants to inverse fourier transform the data themselves, potentially breaking currently working scripts

What are your thoughts on this change? Does this break something else?

[jonschumacher]

Looks good to me.

[tknopp]

I think I would give this a thumbs up as well. My only concern would have been a breakage at later stages (MPIUI and/or reconstruction) but if issues arise there, we can fix them there.

@nHackel: any objections?

[nHackel]

I think this change sounds good! It might be a breaking change, but most recos will probably be fine, since we would have a minFreq anyway/no good SNR for the offset freq (I think).

This, together with #96 and the potential TF change in MPIMeasurements.jl could be packaged as a new treatment of frequencies with no backward compatibility. If we go that route, we should have migration guides in the releases and also check if there are any other breaking changes we want to do

[jusack]

This is not directly related to the original scope of the PR, but I also added new methods for combining TFs (which I need in MPIMeasurements when combining the channel TFs to form the TF to be written into the MDF) and split up the load_tf_fromVNA function into multiple functions.
The reading of the datafile is now done in readVNAdata while the processing of the TF using the calibration coil parameters is done in processRxTransferFunction both of which are called by load_tf_fromVNA. Right now the keyword arguments R,N and A are functional again in load_tf_fromVNA, however, it would be easy to deactivate them for load_tf_fromVNA and just not pass them to processRxTransferFunction. What are your thoughts? Should we "fix" load_TF_fromVNA or keep the behaviour stable?