Process for veto analysis

[lobis]

Added TRestGeant4ToDetectorSignalVetoProcess for analysis of veto events and corresponding tests.

[jgalan]

The process has access to TRestGeant4Metadata through TRestRun.

It is enough to do fGeant4Metada = GetMetadata<TRestGeant4Metadata>(); as it is done in other processes.

jgalan@sultan2:~/rest-framework/source/libraries/geant4$ grep -rnw . -e "GetMetadata"
./src/TRestGeant4NeutronTaggingProcess.cxx:145:    fG4Metadata = GetMetadata<TRestGeant4Metadata>();
./src/TRestGeant4BlobAnalysisProcess.cxx:66:    fG4Metadata = GetMetadata<TRestGeant4Metadata>();
./src/TRestGeant4AnalysisProcess.cxx:286:    fG4Metadata = GetMetadata<TRestGeant4Metadata>();
./src/TRestGeant4VetoAnalysisProcess.cxx:123:    fG4Metadata = GetMetadata<TRestGeant4Metadata>();
jgalan@sultan2:~/rest-framework/source/libraries/geant4$ 

Why do you want to set it externally?

[jgalan]

For me the biggest problem of this PR is that it brings to connectorslib very specific tasks from geant4lib such as accessing the geometry volume, calculating the quenching factor, etc.

I think we should find the time to meet (probably also with @juanangp) and think of an implementation that minimises the coding inside connectorslib.

In my opinion, such minimisation of code inside connectorslib should be done by creating a new TRestGeant4QuenchingFactorProcess that makes use of the Geant4 geometry to introduce the quenching inside geant4lib.

Then, working out an upgrade of TRestDetectorHitsToSignalProcess that makes use of a readout where we can identify different types, "micromegas", "scintillator", "PMT", ...

So, we just use TRestGeant4ToDetectorHitsProcess and then the upgraded TRestDetectorHitsToSignalProcess.