met uncertainty tool (in PAT) fixes for 72X releases

The MET uncertainty tool in PAT has been updated accordingly to the last development changes in 72X releases, and can go to the central release now.

Pat MET names have been also updated in order to match the new naming convention.

Matthieu

@mmarionncern, @Dr15Jones, I was wrong about this struct. I was confused with another class in DataFormats/METReco.

The struct [CommonMETData](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/DataFormats/METReco/interface/CommonMETData.h) is not event content of RECO or AOD. I incorrectly thought CommonMETData is a member of [reco::MET](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/DataFormats/METReco/interface/MET.h). It is not.

I remember my plans for CommonMETData. I was going to delete this struct at some point.

MET producers use this struct to store data temporarily. For example, In [CaloMETProducer.cc](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METProducers/src/CaloMETProducer.cc),
an instance of CommonMETData is created by METAlgo at [L62](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METProducers/src/CaloMETProducer.cc#L62) and is given to CaloSpecificAlgo at [L65](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METProducers/src/CaloMETProducer.cc#L65). Then CaloSpecificAlgo receives as *umet* and makes a copy as *met* for no clear reason at [L29](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METAlgorithms/src/CaloSpecificAlgo.cc#L29) and stores the values of mex, mey, met, and sumet at [L61](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METAlgorithms/src/CaloSpecificAlgo.cc#L61) and [L63](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METAlgorithms/src/CaloSpecificAlgo.cc#L63) to an instance of CaloMET. Anyway, what is essential of CommonMETData in MET producers is three numbers, mex, mey, and sumet, i.e., one vector with two components and one scaler value, which is not very obvious from how the code is written in MET producers, e.g. [CaloMETProducer](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/RecoMET/METProducers/src/CaloMETProducer.cc). I am planning to make it more obvious from the code. When the code becomes more clear, I don't think CommonMETData is any longer used in MET producers because I think this struct is a source of the confusion, at least it was for me when I was reading the code for the first time.


As for the redundancy, [met](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/DataFormats/METReco/interface/CommonMETData.h#L14) is also redundant as it is sqrt(mex*mex + mey*mey). Furthermore, [mez](https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_0_pre3/DataFormats/METReco/interface/CommonMETData.h#L16) is needless.

If MVA and NoPU MET are using CommonMETData, it is ok for me to keep it. But I think that I will make other MET producers stop using this struct at some point. If we keep it, we will probably need to review access specifiers of the member variables.