[HltEfficiencyChecker]: Add support for sprucing

Note: HltEfficiencyChecker is being moved from MooreAnalysis to DaVinci in !1005 (merged). This issue only becomes relevant to DaVinci once that is merged

FYI @nskidmor @rmatev @sstahl @mvesteri

Here's the work I think will be needed to make HltEfficiencyChecker work for sprucing:

• The user needs to specify the level when writing a yaml/"wizard" config file, which currently accepts 1, 2 or both. This could be extended in HltEfficencyChecker/options/options_template.py.jinja to accept e.g. Spruce. However, both would no longer make sense, a better keyword would need to be dreamed up.
• Some sprucing examples (and tests) would need to be written for both .yaml and .py.
• Quite a few changes would be needed in HltEfficiencyChecker/python/HltEfficiencyChecker/config.py where different control flows are set up for HLT1 and HLT2.
• The TOS decisions are given by Phys/DecayTreeTuple/src/MCTupleToolTOSHLT{1,2}. The key difference is that the HLT1 version gets LHCbIDs from the SelReports, whereas the HLT2 tuple tool gets them from the persisted candidates. A sprucing version e.g. MCTupleToolTOSSpruce would be needed, although I guess it would be almost identical to the HLT2 version. Perhaps even the HLT2 tuple tool will just work, or work with minimal changes so an extra MCTupleToolTOSSpruce wouldn't be necessary.
• Then, the two analysis scripts that give efficiencies (HltEfficiencyChecker/scripts/hlt_line_efficiencies.py) and rates (HltEfficiencyChecker/scripts/hlt_calculate_rates.py) need a bit of work, although these scripts aren't that clever since they just make plots/printouts. The efficiencies script looks fairly agnostic to whether its HLT1 or HLT2, so shouldn't be too hard to extend it. The rates script has more to do.
• ... and then the documentation would need to be updated.

So I think it's quite a lot, but quite dull and shouldn't require too much thinking necessarily.