feat: migrate PhotoMultiplierDigi_factory to JOmniFactory

[wdconinc]

Briefly, what does this PR introduce?

This migrates PhotoMultiplierDigi_factory to JOmniFactory. Couple of points of note:

• src/global/digi now has only headers, so the target digi_library is gone; probably could move PhotoMultiplierDigi_factory into src/factories/digi for clarity,
• JANA doesn't support parsing of std::vector<std::pair<double, double>> for quantum efficiency, so that's disabled in the ParameterRef list (@nathanwbrei OT, but having to specify a variable name for these ParameterRef seems useless; can we stick them in a container?),
• the passing of a lambda which captures this and calls m_RichGeoSvc().GetReadoutGeo(GetPluginName()) which in turn has a call_once is janky (but not a change from previous practice...):
  • m_RichGeoSvc() is implicitly modifying the service with call_once (and apparently allowed to; @nathanwbrei can JANA enforce immutability of services?)
  • the RichGeo service as used by the DRICH plugin and the RichGeo service as used by the DIRC plugin are going to be different, maybe, and whoever calls GetReadoutGeo() first gets the call_once flag; that seems dangerous. Putting both PhotoMultiplierDigi_factories in the same plugin doesn't seem like it would be possible. The RichGeo likely needs to be able to support more than one ReadoutGeo and initialize them on demand. It probably needs to fill a map by detector name (not plugin name), with a map of call_once flags or so. @c-dilks any thoughts on where you were going with that?

I think for now this maintains the status-quo, but we need to find a better solution to this in a different PR that reworks this...

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No.

Does this PR change default behavior?

No.

[wdconinc]

No diffs.

[github-actions]

Capybara summary for PR 1177

• rec_dis_10x100_minQ2=1000_craterlake
• rec_dis_10x100_minQ2=1_craterlake
• rec_dis_18x275_minQ2=1000_craterlake
• rec_dis_18x275_minQ2=1_craterlake
• rec_dis_5x41_minQ2=1_craterlake
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake

[c-dilks]

@c-dilks any thoughts on where you were going with that?

One call_once flag for each detector should do it.

The overall design rule I tried to enforce here is "keep detector-dependence out of the algorithms." richgeo is supposed to serve the detector dependent stuff to the algorithms, but it's not as clean as I wanted it to be, as you can see from some of our factories.

[wdconinc]

"keep detector-dependence out of the algorithms."

Definitely appreciate this design philosophy! (and the difficulties that come with it...)

[veprbl]

Diff LGTM