Workaround for the way we're currently hardcoding pflow jet tagging

The workaround for pflow jets

I'm not in love with this workaround, but it's the best option that I can see that doesn't delay the retraining campaign we're supporting with ATLASRECTS-4844.

The "new" neural network code is scheduled per-jet-collection, which gets us around the whole mess of having to pass a jet author through into a series of shared tools which each contain multiple trainings. Unfortunately the pflow jets are duplicated (to allow us to run multiple b-tagging trainings on the same jets) within the same tool that runs the new NN code. This means that it's impossible to configure the two jet collections differently without some hacks which are very specific to pflow jets.

In the future we should really consider duplicating the jet collection before calling the b-tagging tool. This would make handing each duplicated jet collection much easier and move a considerable amount of hardcoded logic into the configuration code. But again, I don't think we can fix this without delaying the retraining campaign further.

Flag to enable retrained flavor taggers

I also added a flag called BTaggingFlags.Do2019Retraining. It is set to False for now. When set to True it will enable:

• Track augmentation: @akraszna, @jcatmore, we have to figure out how to remove these decorations from most derivations that are storing AllVariables for InDetTrackParticles.
• New b-tagging algorithms: These are read out of https://atlas-groupdata.web.cern.ch/atlas-groupdata/dev/flavtag/april2019/. Note in particular the dev/ area: I don't have permissions to move these out of the dev/ area, but I guess we should be really sure things are finalized before either @cpollard or @mkagan makes this move.