*: web, web_editor

Now, the user can edit each individual component of each color preset
thanks to the third tab of the left panel. The edition of the first
preset is the same as the others for the users but it is actually
also used for "no-preset" areas, meaning that they impact the whole
website by default (*without impacting the other presets*). The website
thus appears as areas using presets, preset 1 being the default (in the
future all areas will be customizable with a different preset). The only
difference between "using preset 1 explicitely" and "not using a preset"
will be that background color is transparent in no-preset, leaving the
body background appear. If the body background has no image, then there
is no difference at all as the background color of the body is set to be
the background color of the preset 1. In boxed mode, that color is used
for the "box" and the website body uses a different customizable color.

Note: before this commit, the "text" color edition was used to set the
main text color and one of the constrasting color for the color-yiq
function (the darkest if a dark color or the lightest if a light color).
That last part has been removed and automatic colors will now always
use $gray-900 and $white as contrasting colors, unless changed by the
theme explicitely. This needed to be removed as now the "text color"
edition has been moved in the "preset 1" config and should thus only
impact the "no-preset / preset 1" areas instead of all the presets.

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

*: 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

Commit https://github.com/odoo/odoo/commit/52ec536cef2ec84af0b36746f19a8cdf9f23fe2a
made a mistake which made the backend use the website colors. This is
because the web_editor app adds its bootstrap_overridden.scss file in
both backend and frontend assets as the backend needs the editor colors
(alpha, beta, ...). However, the 'primary', 'secondary', etc that the
backend customizes should not be overridden by the web_editor. Therefore
the file contained a hack to determine if it is the backend or not...
hack which did not work anymore with the new system the mentioned
commit implements.

Also some comments were not adapted correctly by the mentioned commit.

closes odoo/odoo#29935

* 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

* web, web_editor

The logic which chose if the user text color was supposed to be used as
bootstrap "dark" text color or bootstrap "light" text color
(https://github.com/odoo/odoo/commit/8b2dbd1441d6713d9072db03e8d3cb6c2246410f)
was fine when using the default theme with default bootstrap but was not
working as intended in some themes.

This commit also introduces a more accurate and complex method to
determine the correct contrasted color in most cases.

closes odoo/odoo#28468

* web_editor, website_slides

Current system is styling all navbars with the user color. This was not
the expected behavior but it is in fact quite nice, so we decided to
keep it. There was however a problem: choosing the menu text color only
applied to the main navbar (as it was an xpath toggling the navbar-dark
class).

This commit solves the problem by forcing navbar-light to behave as
navbar-dark automatically if the menu background is dark, and this
without any JS or extra CSS rules. This allows to get rid of the menu
text color option.

This commit also reviews the light and dark colors which are used when
website is not installed.

* website

```
$map: (
    test: 1,
    black: 2,
);
@​debug map-get($map, 'test');
@​debug map-get($map, test);
@​debug map-get($map, 'black');
@​debug map-get($map, black);
```

The above code leads to a:
1
1
null
2

This is because maps' keys can be *anything* in sass (even other maps).
In the example, the map is defined with unquoted `test` and `black` as
keys which are understood as the string 'test' and the *color* black.
When asking for the value for the 'black' string key... there isn't any.

This commit forces the use of quoted string as color maps' keys.

Make some changes which are needed for theme migration.

- Theme colors as user colors fallback only (not hard choice)
- Review option dependency system

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

* web, web_editor, website, website_theme_install, portal,
  theme_default, theme_bootswatch

The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:

1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
   the dialog without any risk of breaking the style and also allows to
   not care about lots of technical details.
3) New options have been included. Those were themes options that are
   now generic and which themes can simply adapt without touching the
   customize modal (navbar colors, footer color, navbar layout, fonts,
   body background, ...).

The color palette can now also be customized with user colors.

Using sass functionnalities, color palettes and fonts integration is now
a lot better.

Thanks to @qha-odoo for the original design.

task-31677