First pass at overlay setup in derivations

Much of our code relies on DerivationFrameworkIsMonteCarlo , which is actually not what it means to use. This flag was set based on the "input" being "geant4". For overlay, the input is set to data. What most of these pieces of code actually want to know is whether there is truth information in the input file. Therefore, splitting off a clear "HasTruth" flag, including a separate "HasxAODTruth" flag. Migrating all clients I could identify.

This also brought to light a few places where we use MC / truth information as a proxy for something else (e.g. an unprescaled or different trigger menu). It'd be better if those pieces of code could be migrated to check what they actually intend to look for, but that's beyond the scope of this MR. Here I tried to add some comments to point those places out.

This should be a first step towards solving ATLASG-1532. Following this MR, I can run HION6 through on a test overlay file, with errors coming from b-tagging (perhaps not a surprise, as b-tagging in general doesn't work/isn't used in HI from what I understand). This should be good enough that they can begin testing and iron out any last issues.

Note that in doing this I had to assume a jet calibration, which I've taken as the MC calibration and included a warning. I hope folks will cross-check me on that decision.

@egramsta , @jcatmore , @boeriu , I admit that this is a LOT of lines touched, and there's a chance I've gotten one wrong (I'm human). Please feel free to double check me, and I would suggest not merging this the day before we want to build a release 😄