Add MCDecayTreeTuple ntuples to Monte Carlo output files

There are now three ntuples produced per mode:

* `DecayTreeTuple` containing stripped and reconstructed candidates
* `DecayTreeTuple` containing truth-matched reconstructed candidates
* `MCDecayTreeTuple` containing generated candidates

All three ntuples now include `MCTupleToolPrompt` when running over Monte Carlo data which adds three branches to mother particles:

* `MC_ISPROMPT` Boolean flag with value `0` for secondary particles (i.e. the mother is a daughter of a long-lived particle, long-lived defined in `MCTupleToolPrompt` as being a particle with a lifetime greater than 1e-7 ns, by default) or value `1` for prompt
* `MC_LONGLIVED_ID` Monte Carlo ID of the long-lived particle which caused the mother to be labeled as secondary
* `MC_LONGLIVED_KEY` ?? [:confused:](http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/davinci/latest_doxygen/d7/dda/class_l_h_cb_1_1_m_c_particle.html#a204168f8fcaf280f5a03e5f44ceb638a)

## Patching `MCTupleToolPrompt`

As Patrick mentioned, `MCTupleToolPrompt` has a bug which will cause a segmentation fault when an ancestor is found with an ID unknown to the [particle property service](http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/davinci/latest_doxygen/d3/d6e/class_l_h_cb_1_1_particle_property_svc.html). (I counted about 10 such ancestors when running over a single DST.)

I've commited a fix, so when making ntuples one needs to pull the latest version.

```bash
# Using the same DaVinci version that we use to run the jobs
$ SetupDaVinci v35r1 --build-env
$ getpack Phys/DecayTreeTupleMC head
$ cd Phys/DecayTreeTupleMC/cmt
$ cmt make
$ SetupDaVinci v35r1
```

Ganga will pick up this local version of DaVinci with the patched package when running the ntuple jobs.