Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

erp5_web_renderjs_ui: keep previous focus color

This reverts commit a87db49b.

erp5_osoe_web_renderjs_ui: use display_erp5_dialog_with_history

erp5_osoe_web_renderjs_ui: wi^test

erp5_osoe_web_renderjs_ui: wip test

erp5_osoe_web_renderjs_ui: test

erp5_web_renderjs_ui_test: access page

* Rename WorkflowConfigurator PropertySheet to ConfiguratorWorkflow.
* Add ConfiguratorWorkflowTransition PropertySheet for transition_form_id.
  => Should it be moved to standard 'action' instead?
* Avoid defining Configurator-specific API in Workflow API, such as
  initializeDocument(). TODO: What about:
  - state.getAvailableTransitionList()
  - state.executeTransition()
  - state.getWorkflowHistory()
  - state.undoTransition()
  => erp5_configurator_standard:testStandardConfigurationWorkflow

* Add WORKFLOW.{scripts,transitions...} property which is just a ComputedAttribute
  returning a dict (TODO: Instead of a dict, this should be ContainerTab to have
  objectIds()...).

* Allow a Workflow Script to call another one by overriding portal_workflow.__getattr__.
  With DCWorkflow, `container` was bound to its parent (WORKFLOW.scripts which is a
  mapping), but now `container` is bound to the WORKFLOW itself as Transitions, Scripts
  and Variables are all at the same level. This is not very efficient but this is only
  in DCWorkflow compatibility mode after all.

  The initial implementation was creating a `ScriptContext`, a temporary object with
  all scripts of the current Workflow added. However, this required changing existing
  Workflow Script code and especially this did not work with the following use case:
  1. Script Context is created before calling a Workflow Script.
  2. That script calls a Workflow Script from another Workflow.
     => This will fail as ScriptContext is only created for the Workflow.

This commit is going to be squashed before merging to master.

Ignore for now the differences between ERP5Workflow implemented for Configurator
a long time ago and "new" ERP5 Workflows.

This commit is going to be squashed before merging to master.

Work done by Wenjie Zheng, Isabelle Vallet, Sebastien Robin and myself.

See merge request !1381

as an extra safety measure

and also addition of comments

instead, check for the specifically expected Exception
and in that case return with a warning

Commit updates also testDelete of listbox_zuite accordingly

7a9d47adff (authentication_policy: fix display of password expiration date, 2021-03-25)
was wrong, the date was not properly substituted in the message.

This constraint had a TALES expression making it not apply on invalidated
accounts, but during the transition invalidated -> validated, when the account's
consistency is checked, the account is still in invalidated state, so that
check was ignored, making it possible for users to validate an account without
and account type.

- Use Message, so the comment is translated in display time
- Do edit only if we have some objects deleted from ZODB

- Remove useless conditions of "if True"
- No use to use try-except-else, since all except branches
either raise or return
- Remove trailing whitespaces

* Soap Duplicate and Soap Cancel functions have been discontinued due to lack of usage
* OrderId is now necessary in order to retrieve Transactions

My suggestion of using sorted in
nexedi/erp5!1373 (comment 129103) was wrong,
ERP5 document do not sort in deterministic order. Use a key function to make
sure we get results in same order

See merge request nexedi/erp5!1373

For two reasons:
- In previous version, query would lose Embedded Documents, lacking a left join in follow_up_uid
- In large instances the previous version was many times slower

Also,
erp5_dms: Add a test for Base_getRelatedDocumentList

To check it works correctly with both related (follow_up)
Documents and with sub-object Embedded Files

in 772d8fed (configurator_standard: use specific sale and purchase
business processes, 2020-07-16) we introduced scripts to look up
dynamically accounts to use for expense/income and VAT accounts, from
supply lines, but this accidentally broke the case where no account can be
found on supply lines: in this case, the accounting line was not generated.

Ideally, there should be fallback accounts, to keep the same behavior and
also to prevent generation of incomplete transactions.

Review the scripts, so that the "Dynamic" scripts fallback on the account
defined on the trade model path if not found and introduce new scripts,
where the account is not taken dynamically, but only from the trade model
path, for use on the payable/receivable lines (where we don't want to
lookup the account dynamically, otherwise we'll use same account as for
expense/income)