csc bad channels handling in rechit building updated for unganged me11a

[Directed at  73X]. This updates CSC bad channel handling in local reco to allow extension to unganged ME11A channels. Amazingly tricky to do this because the extra channels are appended to the bad channels conditions data. At the same time I decided it was more sensible to change the way the bad channels data are handled. Until now, each time the conditions data changes, the bad channels information was unpacked and stored in a large vector - one 80-bit bitset for the 80 strip channels of each layer in the CSC system: there are 3240 layers in the system. There is also a 112-bitset for the possible bad wiregroups in each layer. However, with unganged ME11A instead of 80 strip channels, we'd have to increase to 64+48=112 bits for the bad strip channels too. So I've changed the approach so the bitsets for a given layer are filled only when that layer is being reconstructed. This saves on storage at the expense of computing time, which is basically trivial. This change is made in CSCConditions, a class in CalibMuon/CSCCalibration, which is our interface to CSC conditions data. There are NO changes to actual conditions data handling - just how the local reco accesses it once it is available. This is done in RecoLocalMuon/CSCRecHitD, where rechits are built. CSCConditions is also used in SimMuon/CSCDigitizer, but the bad channels part is NOT used there (since we don't know how to simulate bad channels even if we know somewhere in the complex change from detector element to read-out signal something is broken.) So there is NO change to Sim code. I added a new test analyzer for the bad channels handling in CSCRecHitD, called CSCRecoBadChannelsAnalyzer. This has a new config in CSCRecHitD/test. I also updated the sample config file for the rechit builder to 72X/73X level. This is run_on_raw_72X.py also in CSCRecHitD/test. I have run on 2500 events from a real data 2012 SingleMu raw relval sample and dumped all rechits built and find identical output for the new code and the old code. I have also run runTheMatrix.py -s --useInput all and this completes with no errors.
@StoyanStoynev @ptcox 
It seems to me that 112 is both the number of strip channels per CSC layer, and the number of wire group channels per CSC layer. So, even if the number is the same, the meaning can be different.
What if this becomes a `static constexpr` data member:
in the class body, in the `private` section:
````
static constexpr unsigned int stipPerLayer = 112;
static constexpr unsigned int wiregroupPerLayer = 112;
````
in the class definition:
````
constexpr unsigned int CSCConditions::stipPerLayer;
constexpr unsigned int CSCConditions::wiregroupPerLayer;
````