This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.

From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:

- models, which are logical entities that depict the client-side state of
  messaging as a whole.
- components, which are in charge of displaying information from models.

This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.

Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249

Task-1914207

This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.

closes odoo/odoo#39023

Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>

If the visitor closes the livechat window, he is redirected on rating /
feedback / send_transcript screen but he cannot go back to the conversation,
except by reloading the whole page.

Conversation should then be considered as inactive after the first click on X.

This commit close the conversation (set as livechat inactive and send the
'has left conversation' message) at first time the visitor closes the
conversation.

Task ID: 2120210
PR #39939

Before this commit, only the tracked page can start the chat request at visitor
side. Which is a bit sad as the operator can send the visitor a chat request
but if the visitor goes on a non tracked page but has the opportunity to start
a livechat, the chat request won't reach the visitor.

This commit refactor the way a chat request is sent to the client side.
Instead of looking for a opened chat request on every page request,
the chat request information (if any opened) is added to the channel info
that are given to the Livechat button widget.

If the widget receives chat request infos, the widget set himself, before
starting, the cookie of the livechat session using the chat request
informations. Then, the conversation (from chat request) is automatically
loaded as any other opened chat session.

Task ID: 2081550
PR #40274

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

This commit allows a livechat operator to send a chat request to a
connected and available website_visitor.

A visitor is considered as connected if his last tracked website.page request
was within the last 5 minutes.
A visitor is available if he doesn't have an active livechat conversation
(mail_channel with type = livechat).
  - If another operator sent him a chat request
  - Or if the visitor asked himself to speak with an operator
    (via the normal and existing flow)

A livechat conversation is active while the visitor haven't left the conversation.
An operator cannot leave a livechat conversation, only the visitor can.

The flow to send a chat request:
  - On the visitor view (tree or form), operator click on 'send chat request'
    (button or livechat icon)
  - A empty conversation with the visitor pops up at operator side.
  - While the operator didn't send a message, the visitor won't see the conversation.
  - The operator can type a message to the user
  - If the operator close the chat without sending any messages,
    the chat request AND the mail_channel are both deleted.
    In this case, the visitor is then available to send him a new chat request.
  - If the operator send a message, at the visitor's next action
    (page navigation on pages that allows livechat, based on livechat rules),
    the conversation will pop up at visitor side, using the livechat button widget.
    The visitor won't be able to request a livechat conversation with an operator until
    he leaves the chat requested by the operator.
  - Once the visitor leaves (with or without rating) the conversation :
        - the operator is notified that the visitor has left the conversation
        - the chat request is deleted to keep the chat request table clean and minimal
        - the livechat conversation if set to inactive.
  - The visitor is now available again to send him a chat request.

This feature uses the already existing livechat_session cookie mechanism,
so no further code modification was needed to make this work.
It's directly integrated is existing livechat flow.

The chat_request model is only useful to quickly check if a visitor has a chat request
and to send the livechat conversation info to the visitor via the livechat_session cookie.

This commit also add a website_visitor banner info on discuss view :

To be able to quickly see all the relevant information of a website visitor
while talking with in discuss view, a fixed banner have been added.
Only the discuss view will benefit from this because detached chatter window
is to small to display such banner.

Task ID: 34624
PR #2028059

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>

* web_editor, website_blog, website_crm_partner_assign, website_links,
  website_livechat, website_mail_channel, website_mass_mailing,
  website_slides

Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).

Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).

Those allow the user to quickly create a new channel or new slides.

PR: #27110
task-1885419