Was not super visible, especially without HR as the dialog immediately
closes (limitation of the web client), or when an administrator user
massively disables totp.

Show a toast notification indicating the success of the action.

Also fix the logging of `totp_disable` so it correctly handles being
called on more than one record, and change the logging data to
<browse_record> (<logins>) across the board.

Also add a way to provide an action to execute after a notification:
by default nothing happens, which leads to dialogs not closing and
forms not reloading, and there is no good way to show a notification
and/then do some other thing, which is inconvenient.

Before this commit, it was not possible to show a message using a client
action. (e.g. show a success message only with core in Python)

Now, it's possible using a client action. This client action call
displayNotification and so we can use the same options also.

A test is added to be sure that this action do not change the current action

Note: in the future a custom registry may be created in a refactoring
to specific function action registry.

X-original-commit: 8775fd670b6b3ec19a77fc0eab72d2223baa36c8

* = website_forum, stock

Fix for: https://github.com/odoo/odoo/pull/32132

crash_manager.js was using the services while bypassing
ServiceProviderMixin That means all services are duplicated, each having
their own state.
To fix this issue, CrashManager now extends AbstractService. Also
crash_manager is now registered in serviceRegistry instead of being
instanciated on the fly.

The crash_manager now being a Service raise one issue with the tests:
The services are not run for the tests but some tests needs the
crash_manager 'unhandledrejection' listener. For that matter the
services are reenable in qunit. Also the crash_manager's
'unhandledrejection' listener has to have precedence over the qunit
listener as it will handle rejections wich have no reason or are not
Errors.

Part of: https://github.com/odoo/odoo/pull/35209

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

Related to the bug: 1874270

Purpose
=======

Keyboard shortcuts working on BlockUI and can cause some issues when used.

Specification
=============

It should not work and should not be display while some process is being executed.

- add function to remove the "accesskey" attributes to avoid the use of the
  access keys while the blockUI is enable.

- add function to reset the "accesskey" attributes when the blockUI is disable.

- add condition to avoid the "Alt" key to reattribute access keys.

This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.

The main changes are:
  - there is no ViewManager anymore, its work is now handled by the
    ActionManager itself, but isolated in a specific file ; this
    eases a lot of things, as the breadcrumbs handling for example.
  - the ActionManager code is converted to the new coding principles
    and guidelines ; mainly, children widgets communicate with it by
    triggering events up, and not by function calls anymore.
  - the ActionManager layer is now testable, and a lot of tests have
    already been written.
  - the code in other addons has been adapted consequently.

What's coming next:
  - introduce the 'AbstractAction' Widget, and make client actions
    and view controllers inherit from it ; this widget will
    implement a common API that could be used uniformly by the
    ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
    getTitle()...).
  - move the ControlPanel handling from the ActionManager to the
    AbstractAction.

Before this commit, it was not possible to choose the user you want to
chat with in a chat window anymore. This was because the dropdown that
suggest the users appeared under the chat windows since commit
https://github.com/odoo/odoo/commit/7b965a9673a9124e6e045b8a290a156eed402ad5

Indeed, the mentioned commit changed the z-indexes so that chat windows
are still usable when a modal is opened. This was done by making the
chat windows always have the greatest z-index... forgetting this would
make them appear on top of their own autocomplete dropdowns.

This commit restores the feature while keeping the ability to talk while
a modal is opened. See code comments for details.

opw-785162

Internet Explorer doesn't implement 'contains' for document so we make a
polyfill for this method in order to be compatible.

- Fix several contexts where the emoji popover was hidden by a webclient
  element (control panel / ...). To solve this bug, the design has been
  improved to not use popover but instead use custom design (better
  integrated with new chatter design)

- Chat window is now still usable when a modal is opened

- Simplify chatter LESS

If the 'reload' action is triggered right after a view change, the
latter will only be effective if we refresh the page at the browser
level. To overcome this, we clear the cache every time the 'reload'
action is triggered.