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

closes odoo/odoo#45856

Related: odoo/upgrade#1211
Related: odoo/enterprise#10200
Related: odoo/design-themes#218
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

*: mass_mailing, website_blog, website_forum, website_hr_recruitment

Deprecate alpha, beta, gamma, delta and espilon color names and now use
a new color system: o-color-x, with x from 1 to 5.

This will allow to review the colors of all themes to have nice visuals
for the new color combinations classes, without breaking the current
uses of bg-alpha, alert-delta, etc in current websites of customers
(by keeping the old color and classes for compatibility).

This will also allow to uniformize all themes under the same conventions
to enforce BS color override:
- o-color-1 used as primary (as before, for alpha)
- o-color-2 used as secondary (as before, for beta)

Before, some themes were not following the 2 guidelines. The users
using those themes will simply have the possibility to choose o-color-1
and o-color-2 colors accordingly to restore their website without
breaking the new system features.

Another change is that those colors are defined through color palettes
and not theme color palettes. This will avoid them to generate automatic
bootstrap classes which we don't want (alert, btn) and generate the one
we want by ourself.

Note: for mass mailing, the colors and classes also have been renamed
but the system stays unchanged.

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

The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.

This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
  on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
  `is_published` which would just go through the related for no reason.
  Plus, using `is_published` will make the field tooltip more accurate as we
  are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
  related field, which is just a readonly when we are not in a frontend
  context.
- Some create and write function would have security check on
  `website_published` value but that was wrong as the user could bypass that by
  simply writting on `is_published`. For the write method, check `is_published`
  is more accurate as it will cover both case since `website_published` will
  then call the write method on `is_published`

Before this commit, those pages would be flag as noupdate.
If not modified, those view would not get modification on module update, which
is not logic.

Now, those view will benefit from any update. It makes even more sense since
multi-website as those views will never get modified directly (it will COW).

closes odoo/odoo#33920

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

The following series of commits were badly forward-ported:
- https://github.com/odoo/odoo/commit/24a8bce5429eef7139bdd1bc87aa1ef8733670a7
- https://github.com/odoo/odoo/commit/9ef7763ecdf4fb102e49ce68ac4ca3ce7557016e
- https://github.com/odoo/odoo/commit/66d37834284f890c00f00c8ab32ca820f757beb6

Previously, for multi-websites it was decided that:
  - creating a new website would not get already existing apps menu (shop,
    blog, forum..).
  - installing a new app would create the app's menu on existing website

This was decided mostly for technical reason but it is a weird behavior.

This commit saves the installed apps menus in order to copy them on new website
If this default menu got deleted, we ensure a minimalist tree menu for new
website

Note: This also fixes the bug where installing a website_module more than once
(with -i website_module in command line) would create the menu (blog, shop,
forum..) on the first website a second time.

This was because the website.menu.create() overrided in website would
return the last created record in the self loop, thus the last one created
would be the one set to the xml_id (ir.model.data).

This commit closes #27253

Somehow, having theses 2 new `website.page` records created separately from
their `ir.ui.view` would throw an error in dev-xml when installing website
module.
A task has been created in website team to track the origin of this bug.

In the meantime, this commit will avoid the traceback by creating the view
inside the page record. As the page's view is not intented to be inherited, it
is the best way to write it anyway.

Reaching the URL /demo/snippets-debug will now showcase all snippets
*automatically* (if a theme uses different snippets or if the snippets
change in the future, this page will not have to be adapted).

Reaching the URL /demo/bs-debug will now showcase all bootstrap main
components and utilities.