The condition for an organisation to be able to use bank account from
other organisations higher in the group hierarchy should not be the
presence of bank account in this organisation, but whether or not it
acts as an independant accounting entity, and this is defined by the
presence of accounting periods.

@Tyagov @luke 

/reviewed-on nexedi/erp5!288

getObject is not public API. Bonus is we can do one query for all uids

Since it's allowed for multiple sections from same group to post
transactions on the bank account from the parent sections, the bank
reconciliation should use the same logic to be able to reconcile
transactions from any section.

( 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

@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

At and From should not be title cased in "Previous Period At/From Date"
message.

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.

@Tyagov @luke 

See the MR at slapos [here](nexedi/slapos!177).

/reviewed-on nexedi/erp5!283

this is used for file name to download

This report has always been based on "french layout", where there is first
all expenses on one page and all incomes on next page.

In the "british layout", there is only one sheet, showing income -
expense on the same layout ( as we can see today on
 https://en.wikipedia.org/wiki/Income_statement#Sample_income_statement
)

The idea is that we can configure financial section either with two
hierarchies for expense and income to have the french layout, or put all
the "british layout" hierarchy in income and leave expense empty.