auto-invalidate derived images when changing coords

[bertsky]

Fixes the issue described in chat for all processors based on core Python. (Not sure about bashlib processors...)

(I added a warning to the default GdsCollector about the AlternativeImage removal. If and when #576 lands, these should appear in OCR-D logging somehow. 🤞)

Thus, some workflows will work, while others will need to be re-defined.

As I said above, this still does not expose all bad workflows, as it depends whether processors make their image requirements explicit (feature_selector and feature_filter) or not. If they do, we'll at least get exceptions Found no AlternativeImage that satisfies all requirements when running invalid workflows. But if they don't, there might be strange errors (like when 3-dim integer arrays from raw RGB images are passed to algorithms that need 1-dim boolean arrays from binarization) or no errors at all (like when implicit internal binarization happens or denoising is simply missing).

[kba]

LGTM, we should add unit tests though.

[bertsky]

we should add unit tests though.

Indeed. This is actually not that hard to do.

For example, in repo/assets/data/kant_aufklaerung_1784-complex/data,

• take OCR-D-SEG-BLOCK-tesseract, parse a page and modify its Border or Border/Coords or Border/Coords/@points and verify that all /PcGts/Page/AlternativeImage are gone (because cropping was first in the workflow).
• Or take OCR-D-SEG-PAGE-anyocr-BINPAGE-sauvola-DENOISE-ocropy-DESKEW-tesseract-DESKEW-ocropy and modify its Page/@orientation and verify that all derived images with deskewed are gone.
• Or take OCR-D-SEG-BLOCK-tesseract-CLIP-DESKEW-tesseract and modify some TextRegion/@orientation and verify that all derived images with deskewed are gone in that segment.
• Or take OCR-D-SEG-BLOCK-tesseract-CLIP-DESKEW-tesseract and modify some TextRegion/Coords or TextRegion/Coords/@points and verify that all derived images are gone in that segment.