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.
As far as I can see, the framework can not distinguish between MC and data at the run level. I believe this was historic. In the past, when doing merging of Runs across files the framework would gladly merge a MC Run and a data Run with the same run number into one Run. Only Events didn't have this merge problem and therefore were tagged as data or MC.
Now that we use the process history as part of the merge criteria, we no longer would merge a MC and data run together just because they had the same Run number. 
We could now add an 'isData' to the Run, however it might be a bit tricky selecting the correct value for previously written file since it would require reading ahead into the Event (assuming the file even had any Events). I don't see that hppenning for pre2.