Add an algorithm to post-fill cellID encodings

[tmadlener]

This can be necessary if the collection patcher fills empty collections without parameters. However, in some cases it might be necessary to have a CellID encoding parameter set on these empty collections. This is a slightly hacky way of getting these encodings in.

BEGINRELEASENOTES

• Add a CellIDEncodingFiller algorithm to set cellID encoding parameters externally

ENDRELEASENOTES

[tmadlener]

CI failures are unrelated. However, thinking about this, this might be better placed in k4FWCore and a bit more general, something along the lines of

• Set arbitrary parameters
• Either in initialize or finalize
• Guard overwriting existing parameter values

Thoughts @jmcarcell

[tmadlener]

Absorbed #478 for now to at least make some things work. All of this will be properly solved in another way

[tmadlener]

Also absorbed #475 for now and removed the in-event parameter setting for the particle ID meta information. (I think that can be handled in a similar fashion as the CellIDEncoding, but it will be potentially more cumbersome to collect...)

[jmcarcell]

For the CellIDEncoding, this can not be automatically discovered as it depends on what algorithms are going to run. Checking back #478 I have seen that it may not be necessary to fill the CellIDEncodings that we have in Lcio2Edm4hep.cpp now until the very end because:

• If it's an LCIO algorithm, it will take it from the LCIO collection
• If it's an EDM4hep algorithm, and when using EDM4hep input, it will not find it only if it's coming from a LCIO processor. However, given that the digitizers are typically the ones who set these and many are ported or are easy to port, I think for all existing cases, something that would fill these at the very end would probably work.

#478 however doesn't work because the finalize() of the tool also triggers the throw about putting during the event loop, maybe this could be studied. Alternatively, the only other way I see is to specify all of them at the beginning, but that means if you change what you run you also have to change them and we would have to change everything that uses the wrapper which is not very nice.
For the PID stuff, isn't the situation similar?
And iLCSoft/LCIO#223 won't do anything if the input is EDM4hep

[tmadlener]

The problems usually arise when "mixing and matching" Running a full chain in LCIO and converting to EDM4hep at the end is rather straight forward. Coming from EDM4hep and then running the same chain is a bit more tricky, but would can be solved by front-loading the information (I think).

In the end, I don't think we can (and / or have to) come up with a fully automatic solution. I think for the existing large marlin based configurations this information is stable enough to just collect it once and pass it through some pre-processing step to then load it up front. Whether we store a bit more information than necessary would be a secondary concern to me.

Also we want more people to move off of the Marlin wrapper, so this might serve as another nudge ;)