Updated interface of TransferFunction

[jusack]

The old interface of overloading getindex to use for both index access to the underlying data and frequency interpolation could lead to unwanted results, since the datatype of the passed index determined the mode.

I changed to interface to ensure that getindex will only access the underlying data and will not perform interpolation. For the frequency interpolation I made each TransferFunction object callable, similar to the access of the AbstractInterpolation object.

The new interface would look like this:

tf = TransferFunction(...)
tf[1,1] # access the tf at the first frequency component of the first channel
tf(1,1) # access the interpolated tf at a frequency of 1Hz of the first channel

This change will break some code that uses the current implementation, but I added a descriptive warning, when the getindex method fails.

[tknopp]

This is in agreement with the convention used by https://github.com/JuliaMath/Interpolations.jl/ right?

Then I am fine with it. But we indeed would need to port the other packages then (MPIReco and MPIMeasurements). And make proper releases so that nothing breaks.

[jusack]

Yes, I am just forwarding the calls to the Interpolations.jl object that is saved in the TransferFunction, with the exception, that we are adding the channels dimensions.

I will have a look in MPIMeasurements for any places the old interface is used, since I will do some changes for the AW excitation there anyways. If someone else could check MPIReco that would be awesome.

From my side, we can wait with merging/releasing until I have a plan for my changes in MPIMeasurements

[jusack]

As another proposed change I added support for Unitful units to the TransferFunction object. The units are saved per channel in a vector in the struct and are applied when using frequency interpolation. When saving the units there are saved as a parsable string in the h5 file.

The change should be fully backwards compatible, assuming no units for every TransferFunction read from a h5 file, where no unit key is found. If no units are defined, nothing should change to the current behaviour.

To simplify the construction and to avoid confusion between the amp/phase and the complex valued constructor, I changed some of the function signatures to use keyword arguments. That could potentially break external code.

Should we add a keyword option or trait to the tf() call to enable the removal of units or should the user just use ustrip when handling a TransferFunction with units?

[jusack]

From my side this PR would be ready for release. I added additional tests and wrote a documentation chapter on the TransferFunction type. Maybe we can have a quick discussion/review if we still need to fix something in this PR or elsewhere..