NtMaker: call m_event.GetEntry()

This is necessary to update all the branches. Don't know where this
was happening in SusyD3PDInterface...
If we think that we'll have classes inheriting from SusyNtMaker,
we might want to move this call somewhere else. But not for now.
D3PDAna: m_event.mu --> m_event.mu_staco

Replace everywhere mu --> mu_staco. This is the new muon collection
being used everywhere in SUSYObjDef (at least from what I see from the
name of the arg variables...). Initially I switched to mu_staco only
in SUSYObjDef::GetMET(), but this would lead to crashes due to
inconsistent indices (-> out of range).  Now using mu_staco
everywhere.

Processing just 10k random events from 126893.Sherpa_CT10_lllnu_WZ I
get the following yields, which look very reasonable:

```
NTUP_SUSY(p1512)   NTUP_COMMON(p1575)
------------------------------------
Object counter     Object counter
  BaseEle   3672     BaseEle   3675
  BaseMuo   3700     BaseMuo   3737
  BaseTau   0        BaseTau   0
  BaseJet   14322    BaseJet   16544
  SigEle    1978     SigEle    1956
  SigMuo    2337     SigMuo    2437
  SigTau    0        SigTau    0
  SigJet    5213     SigJet    4762
------------------------------------
Event counter      Event counter
  Initial   10000    Initial   10000
  SusyProp  10000    SusyProp  10000
  GRL       10000    GRL       10000
  LarErr    10000    LarErr    10000
  TileErr   10000    TileErr   10000
  TTC Veto  10000    TTC Veto  10000
  GoodVtx   9758     GoodVtx   9742
  WW Sherpa 9758     WW Sherpa 9742
  TileTrip  9758     TileTrip  9742
  HotSpot   9758     HotSpot   9742
  BadJet    9740     BadJet    9722
  BadMuon   9740     BadMuon   9722
  Cosmic    9581     Cosmic    9520
  >=1 Lep   3504     >=1 Lep   3537
  >=2 Lep   703      >=2 Lep   721
  ==3 Lep   108      ==3 Lep   135
```

Note that these are not the same events; to do that exact comparison
one would need to have a small sample that has been processed with
both NTUP_COMMON and NTUP_SUSY (perhaps a signal sample? are these
available as NTUP_COMMON?)
define D3PDAna::d3pdMuons() and use it instead of m_event.mu_staco

The motivation for this change is explained in the
D3PDAna::d3pdMuons() docstring.
D3PDAna: prefer references to pointers

When possible, prefer references to pointers (see for example
Stroustrup TC++PL 7.8). Safer, less characters, etc. All the functions
that are modified are only used internally, so it should not break
anything anywhere downstream.
D3PDAna: define d3pdElectrons(), d3pdTaus(), d3pdJets()

Same reasoning as for d3pdMuons(). I believe that these are the only
collections for which one can foresee having several collections for
the same type of objects.

For electrons and jets, there might be some ambiguity to be sorted out
when calling SUSYDef::GetMET(); we will need to investigate this when
we switch from one collection to another...good enough for now.