DPL Analysis: Add TDatabasePDG as O2 Service - #6594

@jgrosseo @pzhristov currently this will use ROOT's default text database, which is older and, for example, does not contain nuclei. We can add our own copy instead (maybe taken from the latest ROOT?) and use it to initialize the service.

As I side note, I would use the ServiceSpec API, not a singleton, which will cause issues with multithreading once we add it.

That said, at some point it was proposed to use a set of statically compiled constants. What is the advantage of being dynamic, given that in any case you can only load a single ROOT at the time, and therefore you will have a single file available in any case? On the other hand, if it needs to be dynamic, maybe the best solution is to fetch those values from CCDB, no?

@ktf even with ServiceSpec API, it would still be used with Service<> in the task itself, right? We can use this PR as is just to unblock analyses, that need to use it, and later improve the internals. We don't really have to use TDatabasePDG, of course (which is a singleton by itself), but it is familiar for the users. Using CCDB does not make a lot of sense, since the information is really static. I can try to implement something with TDatabasePDG interface, though.

Ok, but this still does not solve the issue with using those quantities in the filters, no? Maybe in the end generating a CXX file from TDatabasePDG is the solution which gives users a single way of referring to those.

I do not see how we can make it completely static and still have lookup-by-code. Something like a bunch of static arrays like float[] masses = {...}; int[] charges = {...}; and an index std::map<int,int> pdg_codes; for lookups?

Closing in favor of #6782