Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

This reverts commit 35b2c024.

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