Switch on ambiguities and piracies

[jonschumacher]

Closes #62

[jonschumacher]

tro3/ThreadPools.jl#36 must be resolved in order to fix the put! ambiguities. We should refactor the struct helpers into a separate package that can be re-used in MPIFiles, MPIReco, and MPIMeasurements. Not sure where to put that package though. Is the scope fitting for a package in the general registry? @nHackel

[nHackel]

Which struct helpers do you mean? Things like toDict, toTOML and so on? Or the "MDF" queries like rxBandwidth and the rest?

For toDict and toTOML, we also have a similar setup in AbstractImageReconstruction and the RecoPlans. However, for MPIMeasurements the resulting dicts and tomls are intended to be edited by humans at time and we have "custom" parsing/constructor logic for each struct. In AbstractImageReconstruction, this things are not intended to be human-editable and so it's mostly recursively walking through the structs. The latter case is mostly internal to AbstractImageReconstruction and at most should be extended in MPIReco.

For toDict or rxBandwith and so on, we could make a package in the general registry but I would still make it MPI-specific

[jonschumacher]

I would focus on functions defined in https://github.com/MagneticParticleImaging/MPIMeasurements.jl/blob/master/src/Utils/StructToToml.jl and https://github.com/MagneticParticleImaging/MPIMeasurements.jl/blob/master/src/Utils/DictToStruct.jl. These functions are not really tied to the MPI packages and we could then use e.g. stringToEnum directly in RedPitayaDAQServer without replicating code or having a type piracy in MPIMeasurements.

[tknopp]

Random thought from outside: I think an MPI independent package for Struct <-> TOML or Struct <-> HDF5 files would be helpful and I would like to see this in the general registry.

I needed both quite recently in MagneticFieldConfigurator:
https://github.com/IBIResearch/MagneticFieldConfigurator.jl/blob/main/test/files.jl#L15
(and lines following)

For Struct <-> HDF5 I here used the fallback Struct <-> Dict <-> String <-> HDF5, which works quite nice.

Whether to couple TOML/HDF5 support in the package, I don't have a strong option. Just wanted express the usual use case.