Add entry-level BIB overlay

[henrygreenhut]

Motivation: This change is motivated by MuonColliderSoft/MAIAConfig#36 to add the ability to overlay BIB decays that contain muons separately from the rest of the BIB. To be done efficiently, this requires the ability to overlay BIB from edm4hep files that contain multiple podio event entries. The current 'OverlayTimingRandomMix' component can only overlay one event per file, and cannot sample events with replacement.

Summary: This PR adds OverlayTimingRandomEntryMix, a separate BIB overlay component that has the capability to sample a specific number of individual BIB decay events, rather than treating each file as one unit to sample. The existing 'OverlayTimingRandomMix' component is unchanged.

Design: OverlayTimingRandomEntryMix has predominantly the same structure and function as OverlayTimingRandomMix, retaining the timing-window and hit-merging behavior. However, it supports:

• fixed or Poisson-distributed overlay multiplicities
• sampling with or without replacement
• multiple files within one entry-sampling group

Providing BIB decays containing muons as separate BackgroundFileNames groups allows their multiplicity to be controlled independently, as described in MuonColliderSoft/MAIAConfig#36.

For BIB samples with multiple decay events per file, a podio reader exposes all event entries in the group for sampling.

Groups configured with OneEntryPerFile instead sample filenames directly and read entry zero from the selected file, as 'OverlayTimingRandomMix' does. This avoids opening every file when constructing a multi-file event inventory.

Performance:
I performed a 200-event particle gun comparison between OverlayTimingRandomEntryMix and OverlayTimingRandomMix, overlaying the BIB of 10/1667 of a bunch crossing. The average DIGI time per event forOverlayTimingRandomMix overlay was 20.78 seconds. The average DIGI time per event with OverlayTimingRandomEntryMix overlay and muons sampled separately was 20.71 seconds.

[madbaron]

Thanks for preparing this @henrygreenhut.

FYI we'll have to take this apart and move it to k4FWcore, where the overlay algorithms now live. In particular, in the spirit of key4hep/k4FWCore#413, if possible we should also try to implement this functionality onto OverlayTiming, to reduce the proliferation of overlay algorithms largely doing duplicated actions.