erp5_data_notebook: Don't add Data Notebook Line if store_history is false. When polling ERP5 from Jupyter, I don't want to create a lot of Data Notebook Line.

This commit adds server-side functionality for the [jupyter-renderjs-extension](https://lab.nexedi.com/Kreisel/jupyter_renderjs_extension). This has no interaction/impact with the existing functionality of the erp5_data_notebook BT.

@klaus mentioned that it is not common practice to return objects of a class (defined in the script). However, for usuability reasons there is an argument to do it here:
Usually when using a jupyter extension, a module is imported an functionality is provided by that module. For instance:
```python
In [1]:
import mymodule as mm
mm.someFunction()
mm.someOtherFunction()
```

To emulate this behavior **and** to be consistent with the [ipython-version (Python 2 Kernel)](https://lab.nexedi.com/Kreisel/jupyter_renderjs_extension/blob/master/renderjs_ipyextension/renderjs_ipyextension/renderjs_extension.py) of this extension I therefore use an object of the class `RJSExtension` which is returned by this script. I am then able to use
```python
rjs = Base_loadRenderJSExtension()
rjs.someFunction()
rjs.someOtherFunction()
```

instead of something like

```python
Base_rjsExtensionSomeFunction()
Base_rjsExtensionSomeOtherFunction()
```

which is much less user-friendly. If there is a better alternative I am not aware of, please comment. Also if anything else is amiss.

/reviewed-on nexedi/erp5!238

Do not use data-gadget-value, as some gadgets may also have sub gadget declarations

Dialog submit button was modified.
Precise where the form_list search is located.
Lisbox does not delete DOM when updating itself.
Use macro when possible.
Translation uses another base_url.
Listbox button were modified.
Relation field rendering was modified.

The links are only visible in desktop display.
Links are only calculated for non module document in form_view/dialog

On smartphone, display the textarea small and increase its size when focused
This behaviour should not be activated on bigscreen, as it make it unusable (difficult to search text for example)

Eventhough diff is large, this commits just removes the default_params
TALES.

`hide_grouping` has no effect here.

When running General Ledger with some node categories that will select
the same accounts more than once, the balance of these accounts were
counted more than once.

fixes #20170313-7F7FA8

erp5_data_notebook: ZBigArray may not be available, add it to well_known_unserializable_type_tuple if possible.

erp5_data_notebook: Don't save ZBigArray in data notebook. It may be too big that zope process may crash.

from commit message
> We have a constraint preventing closing accounting periods if there are still some accounting transactions that are in "current states" (ie. not delivered / cancelled), but this constraint should not be fooled by accounting lines in stock table that does not have an account as node, but just an acquired organisation.

We already fixed another problem where such lines where "getting in the way" in c61cde5b

But here, it's at inventory level, we want to get "all accounting movements from this section during the period"., excluding these "not really accounting" lines.

I used the same approach as the one we applied when we discovered in !215 , there was code doing:
`getInventoryList(node_category="account_type")`
as a way to get only movements on accounts, relying on the facts that accounts have an account type category.  This stopped working and we accepted it because this use case was not really valid. Instead, we did a first query getting all account and passing this as a `getInventory(node_uid=`

I don't think we want to support `node_portal_type` in Inventory API, because the concept of *portal_types* does not really belong in Inventory API to me.

To  prevent creating many portal types (Tax, Discount etc) we concluded:
 * Resources (and Movements) are classified by their *use* category
 * Deliveries are classified by their *ledger* category
 * Nodes are classified by their *role* category

So the "pure" approach is maybe to add a role category on all accounts and query inventory with `getMovementHistoryList(node_category="role/accounting_node")`.

I'd say let's merge this for now, but if you have better idea or anything to add please go ahead, I wanted to create an open place for discussion and explaining why i did all this.

/cc @tc @vpelletier @georgios.dagkakis @Nicolas

/reviewed-on !236

We have a constraint preventing closing accounting periods if there are
still some accounting transactions that are in "current states" (ie. not
delivered / cancelled), but this constraint should not be fooled by
accounting lines in stock table that does not have an account as node,
but just an acquired organisation.

So that ERP5Site_getAuthenticatedMemberPersonValue can really be replaced
by portal_membership.getAuthenticatedMember().getUserValue() (and for
consistency on other ERP5User getters).

git grep -l ERP5Site_getAuthenticatedMemberPersonValue | xargs sed -i 's!\.ERP5Site_getAuthenticatedMemberPersonValue()!.getPortalObject().portal_membership.getAuthenticatedMember().getUserValue()!g'
Plus s/portal.getPortalObject()/portal/g where modified by above regex.
Plus manual edits of the few remaining matches.
Special mention for DiscussionThreadModule_addReply, which forgot to
actually call the script.

This is not a stand-alone test.