Synergistic IO dependency fix

[KrisThielemans]

• Fixes compilation failure with DISABLE_GADGETRON=ON due to syn_utilities #622 (I hope)

Currently sits on top of #1166, sorry. but I'll rebase once that's merged to master. i first wanted to see if this would work. It's really only the last commit at the moment)

[KrisThielemans]

now rebased on top of master

[KrisThielemans]

When using STIR release, we get when building pystir https://github.com/SyneRBI/SIRF/actions/runs/5073309434/jobs/9112163305?pr=1194#step:8:14957

[ 30%] Building CXX object src/common/CMakeFiles/_pysirf.dir/home/runner/install/share/stir/src/buildblock_registries.cxx.o
/home/runner/install/share/stir/src/buildblock_registries.cxx:23:10: fatal error: stir/SeparableCartesianMetzImageFilter.h: No such file or directory
   23 | #include "stir/SeparableCartesianMetzImageFilter.h"

while with STIR master

ImportError: /home/runner/install/python/sirf/_pysirf.so: undefined symbol: _ZTIN4stir8ExamDataE

which might just be the constructor is the typeinfo structure:

$ c++filt _ZTIN4stir8ExamDataE
typeinfo for stir::ExamData

[KrisThielemans]

The above problem is fixed now.

However, I still have a Python problem such as

ImportError: /home/sirfuser/devel/install/python/sirf/_pyreg.so: undefined symbol: deleteTextPrinter

@evgueni-ovtchinnikov deleteTextPrinter is declared in cReg.h, but it is not implemented in cReg*cpp. Is it using the implementation in cstir_tw.cpp? If so, creg depends on cstir, which I then should make explicit in the CMake file.

[evgueni-ovtchinnikov]

Is it using the implementation in cstir_tw.cpp?

Apparently it is - when I do "Go To Definition" on the prototype in cReg.h, Visual Studio shows me the one in cstir_tw.cpp.

[KrisThielemans]

@evgueni-ovtchinnikov this is pretty much finished now. I've tried to give descriptive log messages, so maybe that helps in the review. Most important change is that csirf is now split into csirf (C++ lib) and cinterface-sirf (for Python/MATLAB), and same for cReg. I did this for 2 reasons:

• it's cleaner
• it also avoids the circular dependency of csirf (actually p/msirf) needing cSyn (for ImageDataWrapper), which needs csirf.

There are a few things that we could still do here:

• do the same split cinterface-stir and cinterface-gadgetron
• move iutilities.* (containing C functions for DataHandle) to common (and add it to cinterface-sirf I guess). This is more logical now that we have common. We can then remove the iutilities library (also in Python), but I suppose we'd have to keep it as an empty library until 4.0.
• rename csirf (again) to common. It is the more logical choice.

These things would be nice, but we could also do them later. Would be cleanest to do the first bullet though (and it's very simple, so I can still do that).

[evgueni-ovtchinnikov]

Main comment: I very much welcome suggested changes (thought about them myself, but never attempted for lack of understanding of CMake intricacies), but they look too dramatic to me for 3.5 - should this not go to 4.0?

I need more time to study your PR, for now just one minor comment that cannot wait: frankly, I find cinterface-sirf rather ugly. I would rather use csirf for C interface library and cppsirf for C++ library.