erp5_jexcel_editor: fix tabs and formula bar

erp5_jexcel_editor: remove and rename tabs

erp5_jexcel_editor: fixed delete and rename tabs

erp5_jexcel_editor: add formula from toolbar and real cell value in formula bar

erp5_jexcel_editor: more formulas

erp5_jexcel_editor: fixed merge issue, added warning before merge, fixed formula dropdown, parse formulas and hide js code i the cell, added cell selection input

erp5_jexcel_editor: new  columns types : images, html, color, text, calendar, checkbox

erp5_jexcel_editor: fixed select width

erp5_jexcel_editor: stable version

erp5_jexcel_editor: fixed merge save conflict

erp5_jexcel_editor: fixed formula dropdown, different cursors

erp5_jexcel_editor: formula bar, not working like expected yet

erp5_jexcel_editor: updated jexcel source

added merging cells, more features in toolbar, horizontal scrollbar, searchbar in toolbar

the "failIf..." naming scheme is deprecated in unittest, we should at
least have new-style named methods

So far, simulated tax is not included in printed Orders. This allow to include expected tax in vat_list for printout.

This is done using `getPreferredTaxUseList` which is probably wrong and will hopefully be rewritten using more modern technologies (html not odt) and to use base amount, but this allows to make order printout show tax lines again.

See merge request nexedi/erp5!1168

Firstly, rework a bit the action to create translation data, the action no longer allow choosing the translation data script to update, but uses the one referenced in the translation gadget html.

In post upgrade, compare the actual content of the translation data script with the expected content, calculated from web site languages, data-i18n attributes from referenced pages and Localizer messages.

This makes the requirement that web sites with different configurations for translations need to use different translation gadget stronger, when it's not met post upgrade will always report consistency issues. To address this, modify existing web sites so that they all use different translation gadgets - or at least don't use translation gadget explicitly. 

This was made by:
 - all web sites by default do not have a translation gadget
 - smart_assistant use a dedicated translation gadget, to confirm that using a different translation gadget is possible with an officejs web site, where the translation gadget is defined in the "app" web section.
 - officejs_support_request_ui uses a dedicated translation gadget, because we need this for a customer project and for ourselves.
 - other web sites do not support translation by default, but enabling would be easy: 
    - set the allowed languages on web site
    - create an empty web script ( `{website}_translation_data.js` )
    - create a translation gadget web page ( `{website}_translation.html` ) using same content as `gadget_translation.html`, except that the translation data script should be the one created above ( `{website}_translation_data.js` )
    - configure the web site to use translation gadget in layout properties. In the case of an OfficeJS web site, this should not be set on the web site but on the main web section
    - use "Update Translation Data" action on web site or run post-upgrade step of upgrader.

This revealed problems (page does not load with javascript error) when using different translation gadgets, that were addressed by not pre-loading the default translation gadget.

See merge request nexedi/erp5!1151

![login](/uploads/d270b602f784466dcc8d0806ec0ab9e1/image.png)

![recover](/uploads/da5bca427e6053a4724a4f7171db71db/image.png)

![reset password](/uploads/27e3519dfaf96cd66ce3adf9d6184ba8/image.png)


See merge request nexedi/erp5!1165

This was not enabled, but it's should be OK already

See merge request nexedi/erp5!1170

product/ERP5SyncML/{Transport,Engine}/*.py were not considered.

this is supposed to work

pylint: Fix false positive error `No name 'ElementMaker' in module 'lxml.builder' (no-name-in-module)`.

W: Dangerous default value _MARKER (__builtin__.list) as argument (dangerous-default-value)

Since BusinessProcess.py was moved to portal_components, the cache in mixin/composition.py,
which was kept at the level of the zope process, was causing issue when portal_components
was reset : the classes kept in __class_cache would not get resetted, and later calls
to asComposedDocument would reuse them. In consequence, these classes would kept pointers
to objects in the old class BusinessProcess, causing bugs as these objects would have
been cleaned by the reset.

The first intuition was to remove this cache, unfortunately the reason of this introduction
(fixing a memory leak) is still valid nowadays, so I've decided to move this cache within
BusinessProcess, as it has the advantage of emptying it whenever portal_components is resetted.

For more information of the bug mentionned above, and the trials about removing the cache can
be found in the discussion of this MR :
nexedi/erp5!1032