Clarify expected usage of SimCalorimeterHit and CaloHitContribution

[BrieucF]

The fact that SimCalorimeterHits are already 'ganged' into cells and that individual hits have to be accessed through CaloHitContributions is creating a lot of confusion for newcomers. Given that e.g. SimCalorimeterHitshas no time member, we can see this an EDM4hep level convention (as opposed to just how ddsim chooses to use EDM4hep). I therefore propose to clearly state that here.

BEGINRELEASENOTES

• Clarify expected usage of SimCalorimeterHit and CaloHitContribution

ENDRELEASENOTES

[tmadlener]

I agree with some need for clarification, but I think we have to be careful here. There are several details that might matter. It's not just an "EDM4hep level" convention. It's rather deeply ingrained into DD4hep / DDG4 and as such the grouping of CaloHitContributions into SimCalorimeterHits can also be changed by the sensitive action that is used potentially. I think for most of the use cases things go through the dd4hep::sim::handleCalorimeterHit so the labeling as SimCalorimeterHits are grouped CaloHitContributions holds in the majority of cases. One exception for this will be fast sim samples where it really depends on what the model produces. (For the majority of cases it probably is hits directly, so in those cases each SimCalorimeterHit will have exactly one CaloHitContribution. Another exception is the Geant4OpticalCalorimeter.

It also depends a bit on what is defined as infinite granularity. Most sensitive actions turn each Geant4 step into a CaloHitContribution (at least for calorimeters).

It's not entirely clear to me how detailed we want to get here, as (at least) some of these things are probably too technical / detailed for the "general public".