Fixing DAOD_SUSY20 and VrtSecInclusiveTool
As reported by SUSY ART, a conflict between the old and the new version of the VertexSecondaryInclusive tool rises when both are used during derivation jobs. The old VSITool instantiates and locks decorations right before the new one attempts to access them. The conflict is simply solved by adding a suffix (AugmentingVersionString = "_SUSY20") to the name of the decorations created by the SUSY20 derivation script's VSITool instance.
At the same time it has been noticed that once a specific AugmentingVersionString is set and the old VSITool is also requested to decorate muons and/or electrons (doAugmentDVimpactParametersToMuons = True and/or doAugmentDVimpactParametersToElectrons = True), derivation jobs fail since the VSITool attempts to retrieve a secondary vertex container whose name is missing the suffix above. This MR fixes this issue too, by simply adding the missing suffix in the same way as done by other VSI methods (here for example).
Edit: also cleaned a bit SUSY20.py by removing redundant calls to tools.