`ocrd resmgr`: Circumvent dynamic lookup in the filesystem or resource list with `ocrd-all-tool.json`

[kba]

We have had an ocrd-all-tool.json for the website for a long time now, combining all the tools sections of all the OCR-D processors in ocrd_all. With https://github.com/OCR-D/ocrd_all/pull/362 https://github.com/OCR-D/ocrd_all/pull/379 we now build this as part of the CI and in the docker container. We can use it for more than the parameter listing in the workflow guide, i.e. to circumvent the dynamic lookup of processors for ocrd resmgr.

The main benefits to `ocrd resmgr is that it then works even when no processors are installed on the system.

To make this work, ocrd resmgr CLI should have an additional option --ocrd-all-tool. If set, this will imply --no-dynamic for list-available because it will look up in the ocrd-all-tool.json rather than $PATH or the resources.yml/resource_list.yml.

As @bertsky proposed here:

Perhaps we should also do a --dump-module-dir for each executable and store a dict from executable to module location somewhere?

We should also provide a static list ocrd-all-moduledirs.yml of processor-name-to-module-dir mappings, since in the use case where the processors are not installed, there is no way to look that up.

And potentially even a ocrd-all-resources.yml that is built from full introspection into all the processors during ocrd_all's build. like a fully generated version of the central, manually curated resource list we still have in core.

These files should be stored in

• OCR-D/core's install path (defaults)
• /etc/ocrd for system-wide overrides
• XDG_CONFIG_HOME/ocrd for user overrides

I am not sure yet how exactly to build the software because these files are to be generated as part of ocrd_all's release but used in core. The simplest solution would be alternating processor releases and core releases of ocrd_all.