This commit contain the business template that take a receipt image as a source,
binarize then segmentize it, and apply OCR on it. It then extract the meaning
with regular expressions. The image should already be loaded inside the
image module before it can be read.

The business template contain:
	* The receipt recognition module
	* An extension containing the code that binarize, crop and
	  segmentize the image then analize it.
	* A new type "Receipt" that contain a source image and the
	  field that contain the "total" value
	* A portal skin folder containing the extension externalMethods
	  aswell as the conversion script that call the recognition and
	  update the Receipt "total" field

Improvements (not limited to this list):
	- Easier loading of picture: directly from the receipt page.
	- Easier loading of picture 2: from phone with OfficeJS
	  (or any renderJS) application?
	- Detect when images are sideway and rotate them straight
	- Better "boxing" and segmentation: some lines are deleted from
	  the original image during the segmentation when they are too
	  close from other
	- Modify the neural network (lstm) to increase weight of signs
	  like $, euro, / and numbers
	- Use of a faster/smaller neural network: Most of the time is
	  lost with the loading of the neural network
	- Caching the neural network: See previous statement.
	- Extract currency, date and receipt emettor.
	- Use a neural network for the meaning extraction?

Avoid iterating over all columns known to catalog to then restrict to a
single table by using SQLCatalog API.
Only check for one range column suffix as code anyway relies on the triplet
of columns to be consistently present. Document this in the code and get
rid of now-unneeded range_column_set mechanism.

str.encode() first performs an implicit conversion to unicode using
sys.getdefaultencoding(), which is usually 'ascii'. The 'isort' module
changes the default encoding to utf-8, leading to UnicodeEncodeError
instead of UnicodeDecodeError. Let's simplify all this.

These methods will be used in erp5 catalog view in restricted environment.
Loosen the security on methods which we will use in erp5 catalog view in
restricted environment.

Required as preparation for migrating to ERP5 catalog which itself has an accessor
`isIndexable` which we plan to remain disabled all the time. So better to rely
directly on isIndexable from erp5 site object.

This would also remove the need of evaluating the globals every time.

/reviewed-on nexedi/erp5!314

/reviewed-on !313

Revert "erp5_officejs_afs_directory: add missing allow cross domain header"
This reverts commit 2674afaa.

Revert "erp5_officejs_afs_directory: rewrite custom storages and automate openhub data retrieval via proxy"
This reverts commit f74f420e.

Such default parameters prevent even entering the module once the document
count is large enough.

Do log it, but do not let it propagate.

Since early days of @arnau work on ERP5 components, we have pylint integrated as a way to check the code in components and in python scripts but nothing prevents us from commiting code with lint errors, leaving the problem for the next developer. 

For this, I extended [`CodingStyleTestCase`](https://lab.nexedi.com/nexedi/erp5/blob/88e4b34ff67aa07447f81c8af836feba607843e8/product/ERP5Type/tests/CodingStyleTestCase.py) that was introduced for very similar purpose so that it also  use our tool to check python code. This way,  we can have failing tests when the code do not pass pylint.

What's still not good is that if we want a business template to be tested, we have to explicitly add a test for this business template, but it's also the case for all our "static" tests (naming conventions, HTML validation etc).


A missing feature was that there was no way to get an overview of all the reported problems on a business template. For this, I added a report action on business template that uses the same code to display errors in all *python* code from a business template:

![ERP5_pylint_business_template](/uploads/13613199227884f0340b8f1c40ca4418/ERP5_pylint_business_template.png)
( the lines have direct links to edit python code )

Because `testERP5WebCodingStyle` was already here checking `erp5_web` (well not really because it was no longer using `CodingStyleTestCase` correctly) , I fixed all problems reported by pylint in erp5_web. In reality it only took a few minutes to do this.

PS: I don't know exactly how we could integrate javascript linter in all this. We have a [`test_javascript_lint`](https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/tests/testXHTML.py#L171), but it does not test much of the code written recently because it only checks portal skins. @romain and @vincentB maybe have plans for this. Anyway, it's out of the scope of this.

/cc @kazuhiko @vpelletier @tc 

/reviewed-on nexedi/erp5!308

erp5_mysql_innodb_catalog: add safety LIMIT in z_getitem_by_path and z_getitem_by_uid to avoid fetching all rows in case of empty argument.