Move all pp HLT jet reco configuration to be based on JetDef

Following on from !70788 (merged), this is a cleanup of the HLT jet reconstruction configuration.

Previously we did all configuration based on the jetRecoDict, extracted from the chainDict. Since we factored out the definition of all JetDefinitions, we can now use those configuration objects to configure all algorithms directly without the further need to depend on jetRecoDict. This is more in the declarative spirit of the JetRecConfig package -- determine all your dependencies, and then step through and configure the components needed to satisfy them.

• 25.04.2024: This runs the jet slice -- consistency checking needed. The MET slice seems to generate as well with minor fixes.

  • Fix the Unconventional Track Trigger chains to use the new syntax

• 26.04.2024: Full menu now generates, but config differences are seen

  • Fix config inconsistencies wrt clean r25 nightly
  • Update code comments and any other documentation
  • Clean up code and add helpers to interpret the JetDefinition especially for repeated operations

FYI a few people who might be interested: @pakontax, @miochoa, @cantel. I decided we didn't really need more helpers but maybe will make notes of a couple of changes in how we get some information:

• If you want to know what the trkopt is in BlahRecoCfg, check jetDef.context
• If you want to check generic information about what the jet collection is made from, string-matching jetDef.inputdef.label is quite flexible.
• If you need to get access to the track collection names, grab them from jetDef._contextDic, which is equivalent to flags.Jet.Context.[trkopt].
• To get the trigger jet calibration string, use jetCalibFromJetDef(jetDef)
• The default jet calibration getter has been changed to use the args getJetCalibDefaultString(recoAlg, constitType, trkopt) for easier compatibility both with jetRecoDict and `JetDefinition. The way I call it with the latter is not super elegant, but it's also not too offensive.

@fpastore I did not attempt to use getStep yet -- this needs a big reorganisation in JetChainConfiguration for most cases (some other cases are trivial and I would just do them all together). I have some idea as to how it could work, but it's better to go progressively.