Add a few assertions and comment to make it clearer what is the expected
behavior on related documents and on the category itself when categories
are renamed or moved.

We have this [Do Not Test Required In Field View Form](https://www.erp5.com/documentation/developer/guideline/module/erp5-Guideline.Module.Creation#do-not-test-required-in-field-view-form rule) rule:
> This kind of constraint should be defined in Constraints documents and should to be checked in workflow transitions.
>
> Checking a field as "required" can cause problems like not saving the data when the user clicks on the save button. The same applies to the use of External Validators scripts in fields.

Currency view was not respecting this, there was both required fields and external validator. 
Also, the external validator was using an incorrect way of getting the "context document", so it was not working on RenderJS UI.

We are removing required fields and validator here, because this should be implemented using constraints instead.  To somehow preserve the same behavior, a new constraint is added in `erp5_base` and enabled in `erp5_configurator_standard`. Custom projects probably want to enable this constraint, but (as far as I know) we don't enable constraint by default. 

This  `Base_uniqueReferenceInFolderValidator` was apparently not used anywhere else and not working anymore, so we are just removing it.


/reviewed-on nexedi/erp5!710

This is needed to keep using the translation gadget.
See nexedi/erp5@9d0b0878

   Changes on ERP5Security: Define getFacebookUserEntry to reduce code duplication
   Add facebook support for login and logout (optional) on erp5_core, xhtml and credentials.

Any use of erp5_sql_transactionless_connection must end with an explicit SQL
commit, otherwise it does nothing and it may even leave SQL locks.

Contrary to InnoDB, TokuDB locks on such statement. test_InvoiceViewAsODT
is the only test that does not use erp5_sql_transactionless_connection
(other tests do via IdTool), breaking the next test
(test_PackingListEditAndInvoiceRule) with "Lock wait timeout exceeded" error.

One would except that the tests use the same instance of
erp5_sql_transactionless_connection, and in this case it would not fail, but
for bad reasons, tests alternate between 2 different ZODB Connection instances.

Here is the real fix :

-      output_dict["phone"] = organisation_phone.getDefaultTelephoneCoordinateText() or err("phone")
+      output_dict["phone"] = organisation_phone.getCoordinateText() or err("phone")

[erp5_web_renderjs_ui_test] Update test for Historical Revision Link so as not to display empty diffs

This change is based on the change in DiffTool: 610a15b3
where we don't display diffs for data types whose value is None, '' or empty data types.

When the listbox is in 'select' mode, lines are by default unselected.
Then, user can decide if he want to include/exclude selected lines.

Merge nearly identical listbox handlebars template.

Fix display of the selection checkbox on mobile.

Use label to render cell subgadget, so that clicking on the text modify the checkbox state.

Keep full text search at the end when including/excluding.

Use data- attribute to store the checkbox uid.

Change cursor for listbox line label.

User text query is always considered as an argument of an AND complex query.

Diff Tool: Redirect to the context in case there is selection of more or less than 2 objects in a module for diff

Also, update portal action regarding the module selection and add tests

[erp5_core] DiffTool: Raise error in case the selection for diff in a listbox has object not equal to 2

Change in tests based on change in DiffTool in commit: 610a15b3

Because of recursive diff for iterables which provides with ugly unified_diff, we
patched the DeepDiff class to treat iterables as string itself and then generate
a unified diff which could be displayed in ERP5.

ERP5 Diff Tool is used to get beautified diff between any 2 ERP5 objects as well as different revisions of a single ERP5 object **(both in XHTML as well as renderJS UI)**

This would be helpful in:
--------------------------------
- ZODB History Tab to check the edit workflow history.
- Revision of the ERP5 object, for example: web pages, documents, etc
- Business Template installation

Diff Tool will also make it able to patch one ERP5 object from the diff *(for version 1, we only patch objects which are of same portal type)*. The current version of Diff Tool uses `deepdiff` python library which provides us with patch which can complies(not completely) with CRDT datatype, thanks to which patch application can be less painful.

Diff Tool is able to differentiate between the diff according to type of user, for example, we do not want a normal user to be looking at diff of some internal properties of object(for ex: workflows), but for a developer user, we are fine with it.

How we calculate the Diff of any two objects:
-----------------------------------------------------------
1. Convert the objects to their JSON format.
2. Use `deepdiff` to find out the diff for the 2 JSON objects.
3. Return a beautified JSON Diff

### NOTE:  This MR succeeds the MR related to create correct URL for History tabs: !695 !683

TODO:
--------
- [x] Add tests for beautified diff and patch.
- [x] Diff tool should be working in new UI.
- [x] Fix the pagination.

Example Diff Tool in both UIs:
--------------------------------------
![XHTML UI Diff](/uploads/846b6b7806939a64922e364d309c028c/Screenshot_2018-07-04_at_6.07.46_PM.png)

![renderJS UI Diff](/uploads/ae7021fbf9cf9f952a7d2d4044df8a78/Screenshot_2018-07-05_at_10.34.01_AM.png)

/reviewed-on nexedi/erp5!686

Fit test to new expected behavior.

This reverts commit 1b087745

/reviewed-on nexedi/erp5!718

This reverts commit 7439ab8e

/reviewed-on nexedi/erp5!717

/reviewed-on nexedi/erp5!716

Before, when solving a solver, parsing sub objects of solver_process was done directly synchronously
in solver_workflow. And we had the case where you have parallel transactions solving a solver,
each of theses transactions see remaining solver not in solved state, but once all transaction are
finished, all solver are solved. This could lead to the case where solver_process is never moved
to succeeded. Instead of using serialize (which may lead to conflicts), just use activities in queue
with a serialization tag.