This commit contain a testing business template for the receipt recognition module
test the "Receipt" type update as well as the OCR success and fail on a set of poor

This commit contain binary files that are test images..

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?

/reviewed-on nexedi/erp5!296

Section bank account item list script was using `parent_strict_group_uid` related key but in 772033ed we removed
`parent_strict_group_uid` related key and added support to generate
`strict_parent_group_uid` related key.

 In that case, *Section Bank Account* field on payment transaction was empty  
![Screenshot_2017-06-16_at_18.54.33](/uploads/4f439bf14fb8b4d54df80031d281ce7a/Screenshot_2017-06-16_at_18.54.33.png) 

The 
`TypeError: Unknown columns ['parent_strict_group_uid']`
was only in the log files, because we are still ignoring errors in TALES.

I'm adding tests to cover this script, it's logic should have been tested anyway.

/reviewed-on nexedi/erp5!295

See discussions in nexedi/erp5!257 from background.

Here we try to reduce the differences in indexation methods that use `DELETE` and then `INSERT` (the one who does not always index the same number of rows).

In `z_catalog_predicate_list` the `DELETE` was missing, so in the case of predicate which stopped being a predicate, that predicate was never removed from the table.


/reviewed-on nexedi/erp5!294

@Tyagov @luke 

/reviewed-on nexedi/erp5!288

( and AccountingTransaction_getDestinationPaymentItemList )

772033ed removed
`parent_strict_group_uid` related key and added support to generate
`strict_parent_group_uid` related key

If rows have been deleted before, it's more natural to simply INSERT and
no need for REPLACE

since predicate is scriptable, a document that was once a predicate may
no longer be a predicate next time it's indexed, so we should remove it
from predicate table in that case.

predicate_category was already doing this correctly

/reviewed-on nexedi/erp5!291

@Tyagov @luke 

During development of JupyterCompile several functions have been used and then removed but their portal_skins remain in ERP5. The purpose of this MR is to remove those skins, since they do nothing. The skins in question are Base_displayHTML, Base_displayImage, Base_saveImage, Base_updateLocalVariableDict and getError.

/reviewed-on nexedi/erp5!289

We pass the `HTTP Exchange` that `inquiry` type based methods can take into account the `HTTP Exchange` that triggered them.

This breaks API, but when discussing with @vpelletier we said that at this stage it's probably OK.

I updated `erp5_payline`, the only usage in this repository.

/cc @gabriel @kazuhiko @aurel @georgios.dagkakis 

/reviewed-on nexedi/erp5!245

@Tyagov @kirr 

When someone imported a module in Jupyter they would get a warning for every module they imported like:

    WARNING: Your imported from the module numpy without...
    WARNING: Your imported from the module datetime without...
    ...

This fix shortens those to just one warning at the end of output like so:

    WARNING: You imported from the modules numpy, datetime, ... without ...



/reviewed-on nexedi/erp5!278

<dtml-var sql_delimiter> without ;

This caused two problems:
 - If Xfvb was killed and left a stale lock file, we don't reuse this
   display. After some time we end up having "All display locked"
   exception but no Xvfb process running.
 - Xvfb's slapos is patched to store control sockets and lockfiles in
   $TMPDIR ( nexedi/slapos@58462c24 ).
   We don't have $TMPDIR set in testnodes, but this would be a problem
   if we ever set it.

Because Xvfb can detect a stale lock file upon startup and start anyway,
the easy way running Xvfb for each display and see if it's still running
after a few seconds.

@Tyagov 
 
Added a test to check int64 and float64 Numpy arrays because an error like this existed before:

```
in Base_executeJupyter
     return json.dumps(result)
   Module json, line 244, in dumps
     return _default_encoder.encode(obj)
   Module json.encoder, line 207, in encode
     chunks = self.iterencode(o, _one_shot=True)
   Module json.encoder, line 270, in iterencode
     return _iterencode(o, 0)
   Module json.encoder, line 184, in default
     raise TypeError(repr(o) + " is not JSON serializable")
TypeError: array([[ -245554.,    19410.,  1453313.],
        [ -238947.,    18888.,  1443651.],
        [ -238416.,    18350.,  1444382.],
        ...,
        [ -250816.,    19482.,  1445528.],
        [ -251464.,    18678.,  1444711.],
        [ -253475.,    18786.,  1444842.]]) is not JSON serializable
```

/reviewed-on nexedi/erp5!285

/reviewed-on nexedi/erp5!290

/reviewed-on nexedi/erp5!287

By adding returned_purchase_packing_list_builder and
purchase_packing_list_builder to Alarm_buildPackingList they are used in
tested alarms.

Returned Purchase Packing List and Returned Sale Packing List can be
generated by corresponding orders.

Test are based on testOrder logic and assertions.

By adding Returned Purchase Order and Returned Sale Order it is possible
to operate with reverse logistics: return the goods sold or purchased.