Support for Mixed type PDF's (Saeco Example) & OCR before template matching

[bosd]

The saeco invoice is an example of a PDF with some vital data encapsulated in a image.
Like mentioned in #393

(All the keywords to identify the issuer of the invoice are encapsulated in the image.)
We need to OCR the pdf first, before an template can be reliably matched.

The current strategy to parse this kind of invoice is to pass the whole thing to the Tesseract input reader.
However this is not the preferred method. The tesseract implementations is quite good. But it still has it's flaws.
With the tesseract input module the whole document gets converted into an image, before applying the ocr.
So even the original text elements get parsed and replaced with the results from tesseract.
With the accompanied errors, it misread a 0 (zero digit) for a O (letter).
It can miss comma, dots and decimal separators.

Real world example:

E103184          Onderhoudsset CA6707/10                                        49,99     21 %    1 PCS            49,99

becomes

E103184           Onderhoudsset CA6707/10                                            4999         21%             1 PCS          49,99`

Hint: The unit price changed from 49,99 to 4999

With a lot of creativity there is a way to workaround this.

• Fixup the ocr mistakes artefacts
• Generate some keyword matches from specifc patterns
  I tried it, It get's the job done. With a lot of challenges..

But it would be better if we had an solution like:

• Pass only the images to OCR
• Parse the texts from the PDF directly.

[bosd]

The solution is here 😄 ✨

Added ocrmypdf as an input module. (it is actually more of a pre-processor)
Now we are able to parse this kind of mixed-type invoice.

ocrmypdf has a function to redo-ocr. This is the function we are calling by default for invoice2data. It will leave the exsisting texts unchanged. Images which not have been ocr'ed yet will be processed.

Still, there is the problem, that the pdf needs to be ocr'ed before keywords can be matched.
To solve this issue, ocrmypdf is now a fallback module.

It works like this:
If the default pdftotext input parser failes to match a template. It will check if ocrmypdf is installed.
If it is installed, ocrmypdf is called with the redo-ocr parameters. The result of ocrmypdf will be sent trough pdftotext again and tries to find an template again. The template is found, and extraction of the pdf will start.
See the Saeco example.

ocrmypdf also has a lot of functionality to bring to the table.

• Generating a PDF/A file.
• Optimizes the PDF images, to reduce file size
• deskews and/or cleans the image before performing tesseract OCR (Very handy for scanned tickets and receipts)
  under the hood it uses unpaper for that

Personally I was using unpaper in my pipeline to process scanned receipts before sending them to my invoice2data server. Having the possibility to let invoice2data do it makes it much easier.

You can fully control the parameters of ocrmypdf and it's underlying modules (unpaper, tesseract) by passing your parameters in the input_reader_config dict.

[bosd]

Test coverage is dropping because of this one. So I will add some more tests.

[bosd]

Coverage is 80% + This should do.

[bosd]

@rmilecki Can you review this pr? 🙏

[bosd]

This PR introduces some important functionality. It closes the gaps of mixed type pdf's which previsously could not been parsed.
I'm keen for getting it into production. (Which pulls invoice2data form pypi)
Can either @rmilecki or @m3nu approve so we can merge this.