make install-models to install commonly used models for tesseract, ocropy, calamari

[kba]

Adds targets install-models{,-tesseract,-ocropy,-calamari} to install recognition models by @stweil, @mikegerber, @jze, @chreul to sensible locations in $(VIRTUAL_ENV)/share.

The list of installed models is far from exhaustive and can/should be easily amended.

This is a stopgap solution until we have a proper model repository. I had to re-download models over the last two weeks for different environments and I thought I might as well create a script and ocrd_all seemed like a good place.

I tried to use GitHub locations where possible. If potential traffic spikes from adding model download here are of concern, I can set up a mirror.

[stweil]

I think that's a good idea, and it will help others including me, too.

[stweil]

Thanks.

[stweil]

Did I already mention that I don't like environment variables (with only a handful of exceptions like PATH)? I nearly never use TESSDATA_PREFIX. It is not needed when Tesseract was build for a virtual environment, and I would not propagate its use.

[kba]

I removed the instructions on TESSDATA_PREFIX, they were not working for ocrd_tesserocr anyways.

[mikegerber]

I tried to use GitHub locations where possible. If potential traffic spikes from adding model download here are of concern, I can set up a mirror.

In my experience, the GitHub downloads are painfully slow at times, you may want to consider mirroring them. (I mirored tessdata_best for that reason here: https://qurator-data.de/mirror/github.com/tesseract-ocr/tessdata_best/archive/)

[bertsky]

Good work @stweil @kba.

Just a few thoughts:

1. We are in the middle of a discussion about new rules in the spec how relative filenames (for model files) should be resolved in processors. $VIRTUAL_ENV/share/<processor> is there as well, but surely a processor name is different from a module name like ocropus or calamari or tessdata. Maybe the other options there are more appropriate (like the XDG paths)? – Anyway, this could be changed again in another PR.
2. How about adding (some of) the Calamari models here? Also, some kind of selection mechanism would be nice, so users can easily download and install a subset of these models by name (like TESSERACT_MODELS for Tesseract)...
3. How about adding some Docker configs which include some of these, too?

[stweil]

Regarding Tesseract, my idea is that in the future models will be selectable by their URL, downloaded on demand and cached locally. That's one of the reasons why Tesseract uses the curl library.

[kba]

downloaded on demand and cached locally

That is also what we have in mind for processors in general, hence the cacheable and content-type attributes to mark parameters as (cacheable) remote files.

As I said before, this is merely a stopgap solution to let users benefit from the enhanced models out there now, while model repository infrastructure and processors improve.

[kba]

Since we're already describing the mechanism in our documentation, I'll merge. Better solution work bundling data with processors is upcoming.

[mikegerber]

2. How about adding (some of) the Calamari models [here](https://github.com/Calamari-OCR/calamari_models)? 

(Late to the party.) I have never gotten any useful result from those models, but that may have been my mistake. → should be tested before integration.