Add placeholder producer for new LumiInfoRunHeader and use in EcalLocalReco

This supersedes https://github.com/cms-sw/cmssw/pull/6128.

Very basic producer for LumiInfoRunHeader is added.  There are two different instances of this producer, one running in DIGI and the other in RECO, with different (configuration-level) behaviour.

Currently only the bunch spacing is filled.

The lumiInfoRunHeaderMC has the bunch spacing set at configuration level, with ConfigBuilder automatically setting it to match the configured pileup scenario.  (It runs BEFORE the mixing module in the digi sequence though, to facilitate the eventual plan of having the mixing module steer itself based on this product).  The producer can also be configured to treat the run number as if it were real data (for run-dependent mc purposes)

The lumiInfoRunHeader running in RECO has an if (isRealData) statement.  For data there is a hardcoded list of runs for now.  For MC the product is simply copied from lumiInfoRunHeaderMC.

The lumiInfoRunHeaderMC has been added to the sim event content, but I have NOT added the lumiInfoRunHeader yet to any reco or aod content (it is currently used as a transient product in any case in the ecal local reco).  Proper lumi event content configs should be created at some point to cover this.

Tested 50ns, 25ns, data, fastsim, and heavy ion workflows (plus the weird 101.0 that was problematic before)

Ecal local reco is also adapted to use the lumiInfoRunHeader to switch between 25ns and 50ns behaviour.
yes, maybe it's a newer topic that I came to realize only a few days ago.
It's obvious that the lumi (23 s) data doesn't quite easily fit the IOV picture of the regular calibration setup.
At the run level it's much more reasonable to deal with ES/conditions DB.

These comments are towards a more proper solution, not something of a temporary placeholder nature.
On this super-short time scale I'd rather we addressed your single use case (ecal local reco config) rather than try to solve very quickly the generic problems that don't seem particularly obvious.

This being said, at least for now ("by Monday"), do we really need anything more than just the thing that sets your 25 vs 50 ns parameters (at the ConfigEditor/cmsDriver level, esp if we already have to call something else fairly related to it)?