OCR-D v3 API: fixes

[bertsky]

• The current pyproject.toml does not install eynollah as a namespace pkg in qurator namespace anymore – dfc4ac2 fixes that.
• If indeed a namespace pkg is present, then ocrd==3.0.0b2 still does not work, because importlib_resources says Can't open orphan path – OCR-D/core@1ed38a6 fixes that in core, 1e90257 here.
• The fileGrp cardinalities were still not in the tool json – 17eafc1 fixes that.

[kba]

• The current pyproject.toml does not install eynollah as a namespace pkg in qurator namespace anymore – dfc4ac2 fixes that.

We have got rid of the namespace, as of #133, so at least for eynollah that should not be a problem anymore.

* If indeed a namespace pkg is present, then ocrd==3.0.0b2 still does not work, because importlib_resources says `Can't open orphan path` – [OCR-D/core@1ed38a6](https://github.com/OCR-D/core/commit/1ed38a6a7559bc0c109e8130220de49698796efd) fixes that in core, [1e90257](https://github.com/qurator-spk/eynollah/commit/1e902571ead1b8493376e2ca7d1dc401aefd929d) here.

Still good that the namespace case is addressed in metadata_location.

* The fileGrp cardinalities were still not in the tool json – [17eafc1](https://github.com/qurator-spk/eynollah/commit/17eafc1ccb3980f2bedb5183d45942fc83a838ba) fixes that.

🙏

So, I'll merge this and then merge main, then we should have an up-to-date v3 PR again.

[bertsky]

We have got rid of the namespace, as of #133, so at least for eynollah that should not be a problem anymore.

Oh, I was not aware of this. But my dfc4ac2 will break this – in the sense that qurator namespace gets reintroduced, because setuptools autodetects this case, structurally. (You have to pass where to tell it otherwise.)

May I ask what was the motivation for that? All the other tools by the Qurator team still use that namespace...