Use type to indicate EMCal vs. HCal

[ruse-traveler]

Comparing the energy deposited by a particle in an EMCal vs. in an HCal is a critical source of PID information, and so is critical to both DIS electron identification (eID) and particle-flow reconstruction (PF). Being able to quickly distinguish clusters from an EMCal vs. an HCal was one of the primary motivations behind the proposal for the ParticleCandidate types introduced in EDM4eic#104.

However, an alternative approach was suggested by @veprbl during Reconstruction WG discussions: instead of introducing a new type, we could flag EMCal vs. HCal clusters somehow. This would allow us to utilize the relations and fields already built in to edm4eic::ReconstructedParticle, and this flag would allow us to quickly sort clusters in eID/PF algorithms.

Describe the solution you'd like
We already have a clear numbering scheme for subsystems (see here), where EMCal have system IDs of 10X and HCal have 11X. We could store the system ID in the type field of edm4eic::Cluster, then sorting would be as simple as:

if ((cluster.getType() >= 100) && (cluster.getType() < 110)) {
  /* do emcal things */
} else if ((cluster.getType() >= 110) && (cluster.getType() < 120)) {
  /* do hcal things */
}

These checks could even be integrated as additional code for edm4eic::Cluster. Though this may not be desirable since it would require us to make sure these indices stay consistent between eic/epic, eic/EICrecon, and here.

Describe alternatives you've considered
Alternatively, we could create a new enum that defines 0 for EMCal, 1 for HCal, or something similar. And there is, naturally, the ParticleCandidate approach of EDM4eic#104.

[ruse-traveler]

Actually, I stand corrected. The B0 ECal is an exception.

    <constant name="B0ECal_ID" value="169"/>

[ruse-traveler]

Given that the system IDs aren't necessarily regular, I think a better, more flexible approach would be to use edm4eic::Cluster::type as a bit-field in the vein of edm4hep::MCParticle::simulationStatus.

This has the added benefit of being able to easily accommodate the existing usage of the Jug::Reco::ClusterTypes enum, where 2D cluster, 3D cluster, slice, etc. could be added as additional bits to flip. And this would allow for not only specifying a single type (EMCal, HCal, etc.), but various combinations of conditions (eg. a 3D HCal cluster in the LFHCAL).

We could then add additional code to easily check if a particular bit is flipped.