n0150 muon sys bugfix
sampleName const
update mc weighting methods
update MCWeighter
Made BTagCalib a static pointer in SusyNtTools
updated 3l cutflow code to use MCWeighter
code improvements for MCWeighter
MCWeighter updates, dumpObjects update
comment out 3L cutflow chunkcs in conflict after cherry-pick
MCWeighter::getMCWeight: add protection against sumw=0

for the pmssm samples, I am seeing events that get a weight 'nan'.
This is because when computing the per-process sumw, there are a
handful of events with processes for which the 'genCutFlow___'
histogram has no entries in the bin 'SusyProp Veto'.
Is this always the bin to look up?
I don't know whether this might be a bug upstream: these are pmssm
samples, and I thought that the SusyPropagator issue was happening
only for simplified models. More details in the pull request.

This should be investigated and fixed, but at least for now we can
process these samples (and make a cutflow and compute limits).
allow the user to specify the bin used to compute sumw

This change is to deal with the pmssm samples that have incorrect
counts in the "SusyProp" bin in `n015*` ntuples. While that problem
will be fixed upstream, this solution allows the user to get the
correct normalization by calling for the samples in question:

```
m_mcWeighter->setLabelBinCounter("Initial").clearAndRebuildSumwMap(m_tree);
```

This avoids having hard-coded special cases in MCWeighter (they don't
belong here). Details of the implementation:
- `buildSumwMapFromChain()`, `buildSumwMapFromTree()` now private;
  user should use `buildSumwMap()`
- add convenience `sumwmapHasKey()`
- add `m_labelBinCounter`, `setLabelBinCounter()`,
  `defaultLabelBinCounter()`
- warn on the first N occurrences of sumwmap=0
- clarify `getCrossSection()` logic (avoid multiple return statements)

Tested with Herwigpp_UEEE3_CTEQ6L1_DGnoSL_TB10_050_100_100_2L.
Merge remote-tracking branch 'origin/dbg-mcweighter' into dbg-mcweighter

Conflicts:
	ChangeLog
	Root/MCWeighter.cxx
	Root/Susy3LepCutflow.cxx
	Root/SusyNtTools.cxx
	SusyNtuple/MCWeighter.h
	SusyNtuple/SusyNtTools.h
move rmLeadingTrailingWhitespaces to string_utils
string_utils: import a few functions from SusyXSReader

These functions will be used to check the formatting of the xsec files
before passing it on to CrossSectionDB
move isInt from MCWeighter to string_utils
allow to parse additional xsec files

This feature tries to fix #15
This feature is needed when one wants to process a xsec file that is
not in the `SUSYTools/data/` directory. Otherwise, one gets a `-1`
cross section. Details of the implementation:
- implement `susy::utils::filesFromDir` (if one wants to add a
  directory rather than its files one by one)
- implement `isFormattedAsSusyCrossSection`: the SUSYTools
  `CrossSectionDB` does not perform any check on the formatting of the
  xsec files. Since here we will be dealing with private files, we
  need to verify that they are formatted as they should.
- implement `parseAdditionalXsecFile`,
  `parseAdditionalXsecDirectory`. These two functions call
  `CrossSectionDB::loadFile`. However, before doing that they check
  whether the xsec values we are about to read are already stored in
  the existing `CrossSectionDB`, in which case they warn the user that
  they will be overwritten (SUSYTools does not perform such test, it
  just overwrites the elements of the map...).
- add test executable `test_mcWeighter`
drop SleptonXsecReader
forgot to drop SleptonXsecReader from Linkdef (amend 2d7429b)
Merge pull request #16 from gerbaudo/addnl-xsec-files

Addnl xsec files
Merge branch 'dbg-mcweighter' of github.com:gerbaudo/SusyNtuple into dbg-mcweighter