Reduce/standardize verbosity; minor improvements

[namapane]

• Fix a bug in filling angles in cases where hMass - daughters.MTotal()) < 0.01: since no fillBranch was called in that case, the values from the previous events were taken
• Some improvements to printouts and implementation.

Notes:

• Updated exampleProbabilities.py for the documentation of "addPAux", which was introduced in STXS probs and add auxProb #347; but we would need experts to check what it really does, cf. @AlessandroTarabini's talk, slide 5.
• I plan to also move LHEAngProbFiller to the normal sequence, without adding it to addAllEvents, - some care would be needed when moving it because we probably want to call it only for signals, not for backgrounds.

[namapane]

(@pianonick411 you may want to have a look to the changes and to the question above in the meanwhile)

[pianonick411]

I have found where pAux is calculated in the c++ interface to MELA.

mela.getPAux seems to only retrieve some internal variable auxiliaryprob. See here.

It seems that when computeProdP is called for processes that are not VH, the value of auxiliaryprob is modified. In the linked presentation, the probability denoted with pAux is defined with an integral over eta. I believe that the "integration" over eta is evaluated numerically here and has the effect of integrating out one jet. auxiliaryprob ends up taking on the result of this computation.

Hopefully this clears things up at least somewhat.

[namapane]

@pianonick411, in the last commit I added a small fix since I observed an event which fails the condition abs(hMass - daughters.MTotal()) < 0.01 (it is event 802250 in the MELA_Test file). The problem is that variables should be filled in any case, also in pathological conditions, otherwise the values from the previous event remain in the ttree buffer and are used for the current event as well.
The elif here had "<" instead of ">" so that also prevented the warning message to be printed.
This fix may become irrelevant if we move angles computation to MELAProbHelper but it's a good idea to fix this right away.

I also added filling of qH, mZ1, mZ2, which were booked but not filled; are they actually needed? If not, we could remove these variables altogether.

[pianonick411]

@namapane, I am not sure what is best to do with qh, mZ1 and mZ2. They are useful for debugging MELA, but otherwise only duplicate information that is already present. I lean more towards getting rid of them. If we need to debug, dumping the MELA computation using an increased verbosity is much more comprehensive, anyways.