The navbar in community now looks more like the navbar in enterprise.

Here is a sum-up of the changes in community:

- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
  now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
  now located in the middle part of the navbar.

The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.

Task-ID 1878649

מזל טוב

The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.

Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily

Adapt the css and views to be easier to switch direction

Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language

add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY

Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.

BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.

The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:

$gray-darker          ->  gray 900 (unused before)
$gray-dark            ->  gray 900
$gray                 ->  gray 700
$gray-light           ->  gray 600
$gray-lighter-darker  ->  gray 400 (the old variable was created by us)
$gray-lighter-dark    ->  gray 300 (the old variable was created by us)
$gray-lighter         ->  gray 200

Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.

$border-radius-base -> $border-radius
$border-radius-large -> $border-radius-lg
$border-radius-small -> $border-radius-sm

That was pretty useless, better use the btn-secondary class and add
particular rules to `.btn.fa` if necessary.

BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.

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.