ROOT detector offset

[KrisThielemans]

we currently have a keyword for changing the offset such that the first GATE crystal can be "rotated" to another crystal, such that the new (STIR) zero-th crystal is in the "vertical" position. It was introduced by @NikEfth as otherwise our images come out rotated. See here for an example https://github.com/UCL/STIR-GATE-Connection/blob/acf08710e2046d5d26831f7cb7dcd50e550be989/ExampleScanners/D690/root_header_template.hroot#L57

Example code where it is used is at

STIR/src/IO/InputStreamFromROOTFileForCylindricalPET.cxx

Lines 123 to 128 in e3322df

	crystal1 -= half_block;
	crystal2 -= half_block;
	// Add offset
	crystal1 += offset_dets;
	crystal2 += offset_dets;

There are various problems with this:

• as far as I can see half_block is not initialised. This is probably a bug that I introduced in InputStreamFromROOTFile changes for virtual crystals #617 (although it could be older). It is for instance here but this constructor was not used (and disabled in InputStreamFromROOTFile changes for virtual crystals #617). It might mean that most of the time it will be set to zero but it wouldn't be guaranteed.
• the offset probably makes sense to very few STIR users
• it creates trouble with find_ML_normfactors3D we believe (found by @francescaleek). The symmetry-code there will assume that a block starts at crystal 0, but that's not guaranteed as the user can put in any number. This then creates trouble in the estimated norm factors.

Ideally we resolve this after merging #181 (apologies that this hasn't been done yet!), by introducing a new keyword corresponding to an angle of the GATE "module" or so.

[robbietuk]

What steps are needed now that #181 has been merged?

[KrisThielemans]

half_block addressed in #1012. See also #938 for remaining discussions