----------------------
 Summary
----------------------

The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.

Here is a short summary of the changes that have been made:

  1. New coding guidelines
    - snake_case to camelCase
    - prefix private attributes and methods with '_'
    - jsdoc on most methods
    - one class per module
  2. Rename/Merge some classes
    - 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
    - 'chat window manager' is now included in mail manager
    - 'thread' widget now named 'thread widget'
  3. New model abstraction for mail objects:
    - modules 'mail.model.*'
    - modeling:

                    0..1    0..1        *     *
      ThreadWindow  <------>  Thread <-------> Message
                              /    \
                             /      \
              Thread With Cache     Document Thread
               /      |       \
              /       |        \
        Mailbox    Channel    Support Channel
                      |
                      |
                      DM

    - Thread: the superclass of threads.
    - ThreadWindow: the window component of a thread.
    - Message: mail objects representing messages.
    - Thread With Cache: threads that can be used with search view (Discuss app compatible).
    - Document Thread: represents the thread part of a chatter.
    - Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
    - Channel: mail objects representing channels, including livechat.
    - DM: special kind of Channel for 1:1 communication in the backend.
    - Support Channel: special channel for im_support module.

  This new modeling approach let us easily add features on all threads, such as the
  possibility to put any thread in a small window.

----------------------
 Known issues
----------------------

 [Already Present in Master]

    1. When the Discuss app is in the background with 'Inbox' as the selected
       Thread, when clicking on a document thread preview in the messaging menu
       of the systray, the rainbow man appears.

    2. When a document with the chatter is in the background, when receiving an
       inbox notification from this document thread, the document thread is
       automatically marked as read, which removes the notification right away.

    3. Sometimes, opening a DM window from the "blank" thread window does not work.

    4. Reply-to feature on Inbox is not working: no message is sent in the document
       thread.
    5. On the first login of admin user with demo data, the inbox counter is wrong
       (it displays 6, instead of 3).

       Explanation after investigation:

        > On page load, it fetches the correct number of Inbox messages (3),
          but the server notifies of 3 needaction messages right away,
          so it wrongly assumes these are new needaction messages.
        > Not possible for web client to detect that these messages should not
          increment the Inbox counter while keeping same API.

    6. Notifications for new document thread messages only work when the user sets
       'handle with Odoo' for the Notification Management in the preferences.

        > due to notifications on the longpoll bus for document thread
          messages that come from needaction notifications.
        > requires server-side changes to send notification on the longpoll
          bus to mentionned user.

  [New]

    7. When receiving a message on a unjoined channel, thread window flickers
       ('open' > 'close' > 'open')

        Explanation after investigation:

          > JS logic:

            a) On auto-join, ask server to join the channel and get channel infos.
            b) The info tells the channel is not detached, but JS code makes decision
               to detach it, and tells server the channel is now detached.
            c) From (a), server notifies on longpoll bus the state of channel, which is
               not detached. The web client thinks that the window state of the channel
               has been changed somewhere else, and the channel is now closed.
            d) From (b), server notifies on longpoll bus the state of channel, which is
               detached. The web client opens the thread window of this channel.

          > The flicker didn't occur before refactoring because the web client was only
            updating the model of channel when it receives the longpoll notification.
          > Server behaviour on 1st longpoll notification is necessary for cross-tab
            synchronization for channel window state.
          > New design implies that model and view should be synchronized, hence the
            issue now.
          > Solution: remove server-side thread window synchronization and replace with
            client-side synchronization.

----------------------
 Hacks
----------------------

The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:

      Modeling for messages:

                             AbstractMessage
                              /           \
                             /             \
                    LivechatMessage      Message

      - AbstractMessage: message compatible with the thread widget.
      - LivechatMessage: message used by im_livechat.
      - Message: message used with the mail manager.

      Modeling for thread windows:

                          AbstractThreadWindow
                              /           \
                             /             \
                    LivechatWindow    ThreadWindow

      - AbstractThreadWindow: behaviour share between all types of thread windows.
      - LivechatWindow: window used by im_livechat.
      - ThreadWindow: window used with mail_manager.

The reason for these hacks are twofold:

  1. Use the thread widget in the frontend and livechat external lib bundles.
  2. Do not have a dependency with the mail manager in the frontend and external
     lib bundles.

Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):

- web._assets_utils: regroups the mixins and functions which *can*
  (and so should) be available in every asset bundle

- web._assets_primary_variables: regroups the variables (or mixins
  used as variables) which *can* (and so should) be available in
  every asset bundle

- web._assets_secondary_variables: same as above but provides an
  environnement where all the 'primary' ones are accessible. This is
  for example useful to handle the community/enterprise split:

  // Community primary variables
  $o-pink-color: pink; // enterprise color
  $o-brand-primary: blue;

  // Enterprise primary variables
  $o-brand-primary: $o-pink-color;

  // Community secondary variables
  $o-my-darker-primary: darken($o-brand-primary, 5%);

  => If there was only one variable template, enterprise edition would
     have been able to define its primary color at the end but the
     darker primary would not have been updated. Using the "!default"
     system and putting enterprise definition above would not have
     solved the problem as the $o-pink-color would not have been
     accessible.

- web._assets_backend_helpers: regroups the variables, mixins and
  functions which *can* (and so should) be available in the backend
  asset bundle only. This is especially (only?) useful for bootstrap
  variables overriddes.

- web._assets_frontend_helpers: regroups the variables, mixins and
  functions which *can* (and so should) be available in the frontend
  asset bundle only. This is especially (only?) useful for bootstrap
  variables overriddes.

Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:

- Find another way: your variable is probably useless, use bootstrap
  variables directly or create a variable that will influence the
  value of bootstrap variables. E.g. instead of declaring:
  `$myvar: $bootstrapvar * 3`
  and using $myvar alone, declare:
  `$myvar: 3` and use `$myvar * $bootstrapvar` where needed.

- Declare a copy of the bootstrap variable and use that one. In that
  case, you should also force-set the real bootstrap one to be sure
  they match (this should be done in appropriate templates mentioned
  above). E.g.
  ```
  $o-boostrapvar: 5;
  ...
  $boostrapvar: $o-bootstrapvar;
  ```

- Set your variable to null and set it to your bootstrap expression
  in the file you will need it (where bootstrap variables are accessible)
  without forgetting to add the !default flag to allow overriddes.
  ```
  $myvar: null;
  ...
  $myvar: $bootstrapvar * 5 !default;
  ```

This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).

Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).

This commit basically changes:
- Variables: @​var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @​mixin mixin-world {}
- Classes used as mixin: .my_class() -> @​extend .my_class
    - Here there were no other solution than to convert the use of
      a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
    - Still need to make sure last variable definition is at the
      right place

This is a simple renaming without adaptation.