*: web, web_editor, website_blog, website_event

New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets:
they come with a background color, a text color, headings colors, a
link color, primary button colors and secondary button colors which
will later be possible to customize by the user.

The classes are made so that they are working on two levels. So if a
column receives a color class and the snippet too, everything will work
fine. More than 2 levels are not supported and the editor is made so
those cases should not appear. See o_colored_level class.

Part of https://github.com/odoo/odoo/pull/45856
task-2197038

*: web_editor

Note: this work also prepare the code to be able to support different
font configs per font family.

Part of https://github.com/odoo/odoo/pull/52220
task-2197038

* portal, theme_bootswatch, web, web_editor, website

With less2sass and bs3tobs4 tasks, the assets structure was reviewed to
handle the specificities of both framework and to prepare for our next
odoo tasks. In particular, the assets_helpers and bootstrap overrides
were basically split into 4 parts: utils, primary variables, secondary
variables and bootstrap variables.
(see https://github.com/odoo/odoo/commit/6e4db7d13a926845bf82f5b035afede42d6d5a89)

Using the !default system for the bootstrap variables parts seems now
a good improvement. This is part of what this commit does: adding the
default flag for all bootstrap variables overrides and inverting the
order of the files in the _assets_backend_helpers and
_assets_frontend_helpers templates. This allows to avoid code like this:

portal:
```
$body-bg: white;
```

website:
```
@​if $var != null {
    $body-bg: $var;
}
```

This code makes the body white with portal or equal to $var with website
if $var has a value. The same behavior in the new file order is achieved
with:

website:
```
$body-bg: $var !default;
```

portal:
```
$body-bg: white !default;
```

This order is now also followed for the _assets_secondary_variables
templates (there are only a few).

This commit also make better assets hierarchy by making website inherit
from portal assets (instead of web) and portal inherit from web_editor
assets (instead of web) (thus relying on strong dependencies instead of
installation order which is not always right for migrated databases).

closes odoo/odoo#29757

Commit https://github.com/odoo/odoo/commit/903ff171acbef7f9fe6e533f43b99eba801b200f
lowered the font-size to 14px for the frontend by customizing the
bootstrap variable in the portal app. It changed the web_editor
rte_inline tour accordingly.

This however broke the test on runbot "base" database, as the font-size
in the editor without having installed the portal app was still set to
16px. Commit https://github.com/odoo/odoo/commit/e3bc059c3649a05c12cd3c8099092282c10141b7
only moved the failed test from "base" to "all" database.

This commit unifies the font-size for all frontends by setting it in the
web app. So, after this commit: reports, editor, login screen and
frontend will always have a font-size of 14px no matter the application
which is installed (except themes).

* web, website

- Introduce gray color palettes (needed for themes migration)

- Synchronize BS4 color maps with individual variables (see comments
 about this in the code).

- Review alpha/primary, beta/secondary matching:

Before this commit, we decided that the common way to define a color
palette was defining primary, secondary, gamma, delta and epsilon.
alpha and beta were then forced to primary and secondary without other
possibility.
The new system makes more sense:
1) define alpha, beta, gamma, delta and epsilon
2) primary and secondary will automatically be set to your alpha and
  beta (allowing to style the default UI with BS4-independant
  variables)
3) if you are not happy with (2), you can define primary / secondary
  in your color palette so that they are not automatically set to
  alpha / beta

This commit also changes what classes the editor uses. Background colors
and text colors will now use alpha/beta/gamma/delta/epsilon (not primary
and secondary anymore). For buttons, all the possibilities are suggested
but color duplicates are hidden (so if your primary and alpha are equal,
only one button color is suggested).

* survey, website_slides

Before this commit, the web_editor app created bg and text classes its
own way for theming (alpha, beta, grays, ...). Now the system is far
more automatic by extending BS4 color maps.

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).