RICH Reco Preparations for DD4Hep support

This MR (and those linked to it) lay some ground work for the migration to DD4HEP in terms of support for functionality needed by the reconstruction.

The RICH has rather complex RichDet objects, with a number of pieces of functionality needed by the reconstruction. In a sense during Run1/Run2 they grew to really be extensions of the reconstruction.

With the migration to DD4HEP this needs to change in that the objects in Detector will (both necessarily and by choice) be a lot simpler. Functionality currently in RichDet but not to be kept in the DD4HEP equivalents will be migrated to derived condition helpers. This MR finishes the ground work for this by migrating all uses of RichDet objects in the reconstruction to use a set of these helper objects, defined in the RichDetectors package in LHCb. Everywhere else (at least for the reconstruction) uses these objects so are blind to if underneath they are using RichDet or DD4HEP.

For now, most of the functionality in these wrappers is just forwarded back to the underlying (RichDet) classes. The next step is to start to test against DD4HEP, which will require in some cases porting required functionality either to the DD4HEP classes, or the wrappers, as appropriate.

just to note, the remaining uses of RichDet directly, instead of via the wrappers, is in some legacy packages in Lbcom, RichTools and RichAlgorithms. These are old legacy components, not used by the functional reconstruction but still kept because e.g. used by Boole. This will eventually need to be addressed (by someone...) as well but that is not an aim here.

Needs to be merged with Lbcom!593 (merged) Rec!2648 (merged) Boole!372 (merged)

FYI @seaso @bmalecki @rilollin @bcouturi @sponce