new jet hypo config

This merge request contains code that allows a more direct and understandable configuration of the jet hypo code. The emphasis is in making extensions to the current code easier as new functionality is needed in the future.

The jet hypo has the concept of a "scenario". A scenario labels a set of actions to be performed by the hypo. Simple examples are the dijet scenario, which requires the presence of a diet passing specifiable cuts, and the agg scenario which acts on the jet collection ass a whole. The simple scenario implements the Run 1 style jet hypo where conditions are applied to single jets. A non-simple scenario can be combined with a simple scenario.

The code in this merge request is made up of a number of modules. Those with names like scenario_XX.py (e.g. scenario_dijet.py) are concerned with extracting information from the incoming chainDict and presenting it in a standard form. This information is then used by the code in hypoConfigBuilder.py to initialise a system of AlgTools that are responsible for providing jet hypo objects required by TrigJetHypoToolMT

Future developments may require changes at various levels. It is expected that the most basic new functionality will be the most common: namely a new scenario is introduced which reuses the existing jet hypo comments. In this case a new scenario_XX.py needs to be provided. The modifications to hypoConfigBuilder are limited to adding an import of this module, and adding the new scenario to an internal routing table.

Whether or not the modifications to hypoConfigBuilder should be automated should be discussed within th eJet Trigger group.

Note that, despite the branch name, no markup files are used.

@jbossios @valentem @khoo @peter

Menu experts (@khoo @hrussell @markowen @dzanzi) please note the following:

• The scale factor (SF) used for djdphi and djdeta was changed from 0.1 to 0.01 to match the rest of the SFs (that means that 20 was changed 200, 26 to 260, etc)

• In Run 2, dphi20 requested dphi<2.0, while deta40 requested 4.0<deta. That means that the equivalent of dphi20deta40 in Run 3 would be djdphi200SEP400djdeta. Note please that all chains including XXdjdphi were now changed to djdphiXX0 to match what was actually applied in Run 2. This fixes the ambiguity present in Run 2 where min/max values were in different order b/w dphi and deta which caused Run 3 chains to be implemented incorrectly. This is a bugfix and count differences are expected (higher counts are expected for dphi>2.0 than for dphi<2.0 which is what is observed in the reference files).

Adding the urgent label since this is blocking other developments, this redesign is needed to be merged before continuing with any other development.