Add cmake switch to change geometry between simulation scenarios

[j-kleemann-old]

Currently when a simulation for the angular distribution, the isotropic effiency or the 0°-detector response shall be performed, small changes in the detectorConstruction.cc are necessary or very redudant detectorConstruction.cc for all three scenarios have to be created.
Furthermore the ActionInitialization.cc or other files may have to be adapted.

One could consider adding a cmake switch, which sets a enum or a string variable, which can be used in the code in if statements making it more versatile without the need to change the files.
A enum should at least allow to switch between the five main use cases of UTR:

1. 0°-detector response
2. Angular distribution in g3-setup
3. Effiency in g3-setup
4. Angular distribution in 2nd-setup
5. Effiency in 2nd-setup

Likewise a variable for the run number could be introduced allowing to merge the many detectorConstruction.ccs of one experiment (e.g. 82Se_82Kr) into one file.

[u-eff-gee]

Parts of this have been implemented. In his introductory paragraph, j-kleemann remarked that it is tedious to change the primary generator (angular distributions, angular correlations, or G4GeneralParticleSource), the output quantities (ActionInitialization.cc), and the detector construction when simulating for different purposes. For the first two (generator and output), CMake switches exist now. The latter may have referred to the different SensitiveDetector classes which have to be changed manually in the DetectorConstruction. This is not yet implemented, but CMake can be used to create DetectorConstruction.cc files from a DetectorConstruction.cc.in file, just like utr/utrConfig.h.in generates the utr/src/utrConfig.h file. Together with the USE_TARGETS switch, this would then cover the C++ aspect of all the use cases mentioned in the enumeration of j-kleemann. Macro files will still have to be edited, of course.

In the last paragraph, j-kleemann opted for less redundancy in the detector constructions (and in the construction of the detector classes). The detector constructions of the 2018/2019 campaign have taken this up and tried to avoid redundancy by splitting the total geometry into modules. The redundancy in the detector classes has been reduced by commits between about #300 and #319.