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>

This reverts commit a87db49b.

erp5_web_renderjs_ui: keep previous focus color

See nexedi/erp5@ea219b74

When new password does not match policy, in reset password and change
password dialogs, we used u' '.join([str(message) ...]) to join all
translated messages in a string, but this construct will decode the
str(message) to unicode using ascii, so it will fail when these messages
contain some multi bytes characters.

Extend test coverage to check that these dialogs uses translations and use
non ascii messages in the tests, to make sure we don't have regressions
with this issue.

See merge request !1001

ERP5 does not handle user "account" anymore, it handles "login".
Please use "Add ERP5 Login" or any other login you need instead.

See discussions on nexedi/erp5!547

Enable coding style on erp5_run_my_doc since it now gets installed with erp5_officejs

See merge request !1325

in case the message is defined in the field ('manage_messagesForm' tab)

instead use ValidationError.getMessage API

Depending on how the message is defined.

Before this commit, translation happened typically in higher level,
where the error message was rendered.
but this imposed translation in everything, including mapped messages,
pulluting Localizer with unneeded messages.

This commit introduces getMessage, the logic is:
- If the message is defined in the code that raises, then it should be translated there
- If the message is defined in the field (in 'manage_messagesForm')
then we need to translate in ValidationError class. Caller should
pass translation_service, because we do not want to import it in Formulator

Like xhtml style