Including DYT algorithm into TuneP and PFMuon

Hi, 
this PR is to insert the DYnamic Truncation (DYT) muon refit into the TuneP algorithm, which chooses the best muon track among different refits (originally tracker, global, TPFMS, Picky, now also DYT), according to the track quality. (@rradogna, @ptraczyk)
The output of TuneP (other than being available in reco::Muon as "tunePMuonBestTrack") is passed to the PFMuonAlgo, which can modify the choice by TuneP and select a different track or discard the muon, based on the whole event reconstruction, in particular the effect of the muon on the PF MET. The PFMuonAlgo choice is available in reco::Muon as "muonBestTrack". So also PFMuonAlgo (and PFCandidate) needed some adjustments to handle the new refit type. 
In the attached plot by @rradogna, you can see a comparison between the performance of the original TuneP (blue) and the new TuneP with DYT (red) in reconstructing the pt of muons from a SingleMuPt1000 gun sample. The green distribution shows the selected pt between Picky or DYT, when available. It can be seen that the performances of the old and new TuneP are similar, but the new one has less tails (compare RMS, overflow). Note that both DYT and Picky will be further optimized later. 
More performance plots from a Zprime(2250) sample can be found here: 
http://trocino.web.cern.ch/trocino/Temp/2014-10-27_NewTuneP/
Blue plots are for the old TuneP/PFMuonAlgo, red plots are for the new version. You can see the pt resolution of "tunePMuonBestTrack" (from TuneP) and "muonBestTrack" (from PF) for all muons with a valid inner track ("AllMuons_"), for muons passing the HighPt selection ("HighPtMuons_"), and for muons passing the PFMuon selection ("PFMuons_*"). In all cases, you can see an improvement in the resolution, especially the tails. There's also a PFMET distribution, which looks significantly improved. 
@abbiendi, @battibass, @bachtis, @bellan 
![tunep_performances](https://cloud.githubusercontent.com/assets/5376758/4790113/595fe06e-5dcd-11e4-9858-7491915bf110.png)
What do you think to had the check for pt>0 in line 49:
 if (refit[i].first->numberOfValidHits() && (refit[i].first->ptError()/refit[i].first->pt()<dptcut || dptcut<0)) -->
 if (refit[i].first->numberOfValidHits() && (refit[i].first->pt()>0) && (refit[i].first->ptError()/refit[i].first->pt()<dptcut || dptcut<0)) ?
in this way checking prob[i]>0 we will be sure that pt>0 is verified.