erp5_web_renderjs_ui_test: cover case of orange highlight not displayed in rjs_gadget_erp5_emailfield_js with test

store error_text to be propagate to render()

This allows crawlers like wget to also fetch the rendering gadget without executing any JS

See merge request nexedi/erp5!1344

This will be needed for DCWorkflow to ERP5Workflow migration so this will be
a core Document and make bootstrap easier.

Nowadays Line Report works fine in ERP5JS. It is also useful in context of MRP.

See merge request nexedi/erp5!1347

This shows the asset price from `stock.total_price` which can be just the
movement prices or the evaluated prices if getDestinationAssetPrice and/or
getSourceAssetPrice type based methods are defined.

erp5_trade contains Base_viewTradeFieldLibrary which contain
my_dialog_mode_portal_type, which is a multi list field where user can
select multiple lines portal types. It is used in
DeliveryModule_viewDeliveryLineReportDialog/your_portal_type

erp5_item also contains Base_viewTradeFieldLibrary , for cases where
erp5_item extend trade module to select items. It also contains a
my_dialog_mode_portal_type field, where user can select item portal type.
That field is not a multi-list field, but a list-field. It is used in
DeliveryLine_viewSelectItemListDialog

So when erp5_item is installed, it overrides
Base_viewTradeFieldLibrary/my_dialog_mode_portal_type with a list field
instead of a multi-list field and breaks
DeliveryModule_viewDeliveryLineReportDialog, because user can no longer
select more than one portal type.

This renames the field in erp5_item, now we have:
 * Base_viewTradeFieldLibrary/my_dialog_mode_portal_type for movement
portal types
 * Base_viewTradeFieldLibrary/my_dialog_mode_item_portal_type for item
portal type

Until now it was only used in ERP5Catalog where the expression property is
`expression` for both Python Script and SQL Method but this is a common pattern
and will also needed for ERP5Workflow.

Instead of generating the report in one big activity, split the calculation
in several batches, so that the processing can be distributed on zope nodes.

The limit for the number of lines was also increased from 10000 to 100000

Using an absolute URL for gadgets cause the gadget to have a different URL
per language when the web site uses "Language in URL" feature.

Using absolute URL is not good for cache and also it seems to cause
incompatibilities with recent versions of ERP5JS. Using relative URL is
what we usually do, it does not have cache problem and works fine.

These modules contain movements and this export is a generic export usable
on any movement type, that can also be useful in MRP modules.

This was enabled in all order/packing lists modules from trade except this one.

This export uses selection, which use to be not supported in ERP5JS, but
nowadays it is supported, so let's enable this report in ERP5JS as well.

See merge request nexedi/erp5!1345

for consistency

for consistency

Even though it was enabled on packing list, this report was showing orders.

This report can be used for purchase, then it shows supplier. In the
report dialog, we have "By Third Party" report mode, so use consistent term.

This report shows packing lists, but in the dialog we could only select
the states of orders.

a928abd2 (web_renderjs_ui: use lxml to extract data-i18n messages, 2020-12-14)
was an old version of the patch that was pushed accidentally. This applies
the missing bits.

This is already working for multi-column conditions (among other malformed
values), but in the monocolumn case the type-check treats None in the same
branch as sequences, which cause the error:
  TypeError: 'NoneType' object is not iterable
As the condition is already covered for multi-column case, put this test
in the monocolumn codepath.

form_discussion_view embeds an editor, but it did not expose notifySubmit
method to child gadgets. Because using Ctrl+S in the editor calls
notifySubmit on parent gadget, Ctrl+S was causing a page crash.

Expose such a method that would submit a comment when called.

The previous regular expression based approach sometimes could not extract
message properly. Using xml parser simplify code and fix several messages
that were not extracted properly, like messages containing ", [] or {}

This also fix some problems when looking for messages sources:
  - archived web pages were sometimes used instead of published ones
  - messages from gadgets implemented as page templates/OFS files were not
    extracted.

A few more unit tests for the scripts involved in this process are added.

Fixes the handling of:
- non-sequence dependency_value
- incorrect dependency_value length
- None in dependency_value
- None in dependency_value items

So more sequence types are accepted by _getExecutableMessageSet.

See 6c4f7600