Update all clients to work with the new transient version of the HepMcParticleLink class

The changes in this merge request migrate Athena to use the new transient HepMcParticleLink version and write out the HepMcParticleLink_p2 version by default. (This merge request follows on from !20197 (merged). These changes are based on athenaprivate1!16561.)

There was a weakness in old HepMcParticleLink that it could only point to one McEventCollection. Hard-scatter and pile-up HepMC::GenEvent objects were all stored in the same McEventCollection. The HepMcParticleLink attempted to identify a specfic HepMC::GenParticle using the barcode and event number. Due to the fact that the hard-scatter and pile-up events are from different samples it was perfectly possible for a pile-up HepMC::GenEvent to have the same event number as the hard-scatter HepMC::GenEvent. In such cases HepMcParticleLink would loop through the HepMC::GenEvent objects in the McEventCollection and link to first the HepMC::GenParticle with the matching barcode that it found, leading to incorrect links. Not much of an issue for standard production without pile-up truth, but crippling if pile-up truth was being used as the input for Truth-seeded tracking... The solution is to have one McEventCollection per input dataset (i.e. one for each of the hard-scatter, low pT minbias, high pT minbias etc.). In standard production everything looks the same, but when pile-up truth is being saved then we would have three McEventCollections typically. The new HepMcParticleLink constructor now takes an optional argument to point it to the correct McEventCollection.

This merge request updates the transient HepMcParticleLink code to enable it to point at multiple McEventCollections.

This merge request also tweaks the HepMcParticleLink::eventIndex() method such that it now returns the event number of the linked HepMC::GenEvent. The old behaviour was that it would return the position of the linked HepMC::GenEvent in the vector of HepMC::GenEvent objects owned by the linked McEventCollection. The there is an optional argument of the constructor where it can be specified whether the event number or the position in the McEventCollection is being supplied.

The output root files should be directly comparable due as the persistent versions should be the same. The only change in sim/digi/reco output that is expected is in leaves holding m_partLink.m_mcEvtIndex. As the m_mcEvtIndex variable changes from representing the position of the linked HepMC::GenEvent in the vector of HepMC::GenEvent objects owned by the linked McEventCollection to being the event number of the linked HepMC::GenEvent.

Summary talk from SPOT#8 here: https://indico.cern.ch/event/721374/contributions/2965501/attachments/1631503/2601151/SPOT.pdf