Reverse the direction of the ParticleID relation(s)

[tmadlener]

BEGINRELEASENOTES

• Remove the relations from Cluster to ParticleID
• Remove the relations from ReconstructedParticle to ParticleID
• Add a OneToOneRelation from ParticleID to a ReconstructedParticle
• This is a breaking change for both existing files and interfaces. There will be no schema evolution for this change
• Add a new edm4hep::utils::PIDHandler and some related utility functionality to help with handling the necessary meta data.

ENDRELEASENOTES

Fixes #251, Fixes #217

Associated PRs (need to be merged at the same time to not break the nightlies completely)

• key4hep/k4EDM4hep2LcioConv#51
• key4hep/k4MarlinWrapper#181
• key4hep/k4SimDelphes#117

Open questions (so far):

• Does the ParticleID still need the type and algorithmType members. In principle at least the latter now can be entirely encoded in the ParticleID collection, since in principle each algorithm can (should?) produce its own collection?
  • Probably not strictly, but we keep it around for now to not complicate this further.

[tmadlener]

I have added a first version of a PIDHandler class that can reverse the direction of the ParticleID -> ReconstructedParticle relation.

Since EDM4HEP::utils now becomes an actual shared library, I have renamed the target because otherwise we will just get a libutils.so which might clash. To ease the transition for now, I add back the EDM4HEP::utils target for downstream consumers, but we could also consider simply breaking things entirely.

[andresailer]

Thanks for the documentation! It only allows me to offer a minor nitpick.

[jmcarcell]

Suggested change

	for (const auto& pid : getPIDs(reco)) {
	if (pid.getAlgorithmType() == algoType) {
	return pid;
	const auto& [begin, end] = m_recoPidMap.equal_range(reco);
	for (auto it = begin; it != end; ++it) {
	if (it->getAlgorithmType() == algoType) {
	return *it;

The vector of PIDs doesn't need to be created

[tmadlener]

I was going for some code reuse, but good point. Changed.

[jmcarcell]

The problem here is that the exception messages are very cryptic:

terminate called after throwing an instance of 'std::bad_optional_access'
  what():  bad optional access
zsh: IOT instruction (core dumped)  ./a.out

so encouraging not checking is not great. At the same time I think this part is too verbose, we don't need to teach std::optional here.

[tmadlener]

Maybe I have to reword this a bit. The section here introduces the assumptions we make in the examples below. This should not be read as encouraging using value directly. If we do the proper checks, the examples get rather long.

[jmcarcell]

Maybe somewhere it should say that it's not mandatory to use the PIDHandler and one can iterate manually? For example if each reco particle needs to be accessed once for a given PID algorithm, then it's not necessary to build a map.

[tmadlener]

Good point. Done.