Cluster EMCal vs. HCal flag

[ruse-traveler]

As discussed in EDM4eic#122, it is critical to PF to be able to flag calorimeter clusters as electromagnetic or hadronic. The type field of edm4eic::Cluster is a natural place to store this information, and we already make use of it for flagging 2D vs. 3D, and slice clusters in the BIC workflow.

While in the long-term, this will require a data-model change - which I will elaborate on in EDM4eic#122 - I believe in the short-term we can implement an interim, minimally-invasive solution that will enable development of critical PF components.

Describe the solution you'd like
Ideally, the type field could be used as a switch, e.g.

  switch (cluster.getType()) {
    case <EMCAL>:
      /* do emcal things */
      break;
    case <HCAL>:
      /* do hcal things */
      break;
    default:
      /* etc */
     break;

In EDM4eic#122, it was proposed to fill this field with the system ID of the calorimeter. This is not ideal since most calorimeters follow a consistent number scheme where the EMCals have a system ID of 10X, and the HCals have a system ID of 11X, but there are a few exceptions. For example, the B0ECal has a system ID of 169.

Instead, we could extend the existing and already used Jug::Reco::ClusterType enum to include flags for EMCal and HCal clusters:

enum ClusterType : int32_t {
  kCluster2D    = 0,
  kCluster3D    = 1,
  kClusterSlice = 2,
  kClusterEMCal = 3,
  kClusterHCal  = 4
};

Then, so as not to interfere with the types already in use, the EMCal vs. HCal flag can be set only in the final stages of calorimeter reconstruction, i.e. the CalorimeterClusterRecoCoG and EnergyPositionMerger algorithms.

Describe alternatives you've considered
Some other solutions are discussed in EDM4eic#122.

Additional context
This falls under the PFAlpha development strategy proposed in this talk.