This PR redesigns all headers and improves and adapts some related features.

**New Header redesigns:** 
All previous header designs have been removed in favor of the new redesigned set of headers.

**New Elements feature:**
This new feature allows the user to select the elements he wants to display in the header (e.g. social links, call to action, ...)

**Mobile menu feature:**
Since we decided to keep the mobile version with an "off canvas" layout, the Mobile Menu feature has been removed.

**Alignment feature:**
This feature has been adapted to match the new headers.

**Mobile Alignment Feature:** 
Since the mobile header layout is always "off canvas", this feature allows the user to choose the menu alignment for the mobile version.

Requires: 
- https://github.com/odoo/design-themes/pull/651
- https://github.com/odoo/upgrade/pull/5214

task-3060986
task-3474743

Co-authored-by: Brieuc-brd [brd@odoo.com](mailto:brd@odoo.com)
Co-authored-by: robinlej [role@odoo.com](mailto:role@odoo.com)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This PR introduces a general redesign of the Portal user interface in order
to give it that fresh and sleek vibe we also introduced in the backend. 

A list of the different changes can be found below. It includes redesign
of some elements as much as layout modification, or element additions.

---

# Main key changes

### Introducing pictograms

It is now a common practice to use pictograms across the UI when it comes
to illustrate a concept related to a module but not the module itself.
With the new cards layout, we implemented these pictograms to illustrate
what each card is about and provides the user some context.

<img width="885" alt="image" src="https://github.com/odoo/odoo/assets/128030743/e9746085-0e9a-4b68-bea2-e21f514e8b3b">

### Layout and design update

With this PR, portal is receiving several design changes, as the card layout
on the home page as mentioned earlier. We also changed the general UI,
removing  custom `background-color` and aiming to something clean and sleek
in the same vibe as what we introduced in the backend.

### Improved responsiveness

With this new fluid layout, Portal gets a better responsiveness and benefits
from a better layout at all media query, with different structures, always
showcasing the essential information.

### SCSS files revamp

We also took that opportunity to clean our SCSS files and remove custom
declarations that were not needed anymore. We tend to reduce the amount
of custom CSS and making use of our BS or Odoo classes.

task-3046004

Co-authored-by: fdamhaut (FLDA) <flda@odoo.com>
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>

Purpose
=======

Make it possible to compare analytic values between plans by inputting
up to one account per plan on each line.
For instance, if we have 2 plans: "Country" and "Product Type", with the
following accounts

| Country | Product Type |
| ------- | ------------ |
| BE      | Drinks       |
| LU      | Food         |

And the following invoices:
* 1000€ of drinks in Belgium
* 2000€ of food in Belgium
* 3000€ of food in Luxemburg

We want to be able to display the following pivot tables:

|     | Drinks | Food | Total |
| --- | ------ | ---- | ----- |
| BE  |   1000 | 2000 |  3000 |
| LU  |      0 | 3000 |  3000 |
| Tot |   1000 | 5000 |  6000 |

|        | Total |
| ------ | ----- |
| Food   |  5000 |
| * BE   |  2000 |
| * LU   |  3000 |
| Drinks |  1000 |
| * BE   |  1000 |
| Total  |  6000 |

Implementation
==============

* Each analytic plan corresponds to one field on `account.analytic.line`
* The fields are added dynamically in the views.
* `account.analytic.plan` doesn't have a `company_id` field anymore,
  meaning that all the companies have access to all the plans. This
  means that the applicability fields and lines are now company
  dependent, and those can be used to know which fields/plans to display
  for which company.
* There can no longer be one "Project" plan per company, even if the
  accounts of that project can still be owned by only one company.
* There is now only one method to get the default (or "Project" plan),
  which is `_get_plan_columns`

task-3497653

# Purpose

Currently, the templates of Knowledge only contain static HTML with text, images, tables, lists, etc. Now, we would like to include templates featuring databases and article links. It will then be possible to showcase more advanced features of Knowledge.

Unfortunately, these elements refer to an article and require an article id to work properly. For the article links, for instance, we need to provide the id of the articles we want to open. When applying a template, the system will generate new articles with new ids. To ensure that the links will redirect the user to the right article, we have to update the ids stored in the document and provide the ids of the newly generated articles.

As the templates are static and the ids are dynamic, we cannot properly integrate those elements in a template. This commit aims to eliminate that limitation by providing a magic `ref` function that people can use in their templates to refer to an external record. People will then be able to easily integrate databases and article links in their templates.

This commit will also introduce new templates containing databases and article links. People can then use those templates to try out the more advanced features of Knowledge and understand the power of Knowledge with real world examples.

## Technical aspects

To streamline our code base, we will merge the model `knowledge.article` with `knowledge.article.template`. That way, the articles and the templates will always be consistent. By merging the two models, we will not have to duplicate the logic and the views for the template preview. It will also not be necessary to: transform the favorites set on the embedded views, update the default values set in the context, etc. when turning a template into an article.

During the development, we considered different approaches to tackle the existing limitations of the static templates:

1. We considered making the ids optional by introducing fallback mechanisms. The idea was to use the id of the active record when no id was provided. This would have allowed the integration of embedded view of article items without providing any id. However, the approach was very limited: it was not possible to list the article items of another article or insert an article link.
2. We considered patching the generated template with `lxml` to update the ids stored in the document. The solution didn't work very well: In some cases, it was not possible to know if the ids should be transformed or not as the ids could refer to another model.
3. We considered turning the static templates into dynamic templates using `QWeb`. The solution was checking all the boxes but we preferred not to allow non-admin users creating templates and using `QWeb` because the rendering engine relies on the `safe_eval` function which can potentially have undiscovered security flaws. To not take any risk, we prefer not to use that approach.

For all these reasons, we prefer including a magic `ref` function in the templates and post-process the template to replace the `ref` function call with the appropriate id. With that approach, people can explicitly tell which id should be dynamically transformed.

task-3334717

Currently, the templates of Knowledge will only contain static HTML with text, images, tables, lists, etc. Now, we would like to include more advanced templates containing article links, index structures, kanban/list views of article items, etc. Unfortunately, there are a few limitations with static templates that prevent us from integrating those blocks:

1. To load a kanban or a list view of article items, we need to encode the id of the parent article in the body of the template. As the ids we need to provide are dynamics, we can not hardcode them directly in the body of the article.
2. For the embedded views of article items, we may define custom favorites that will also be encoded in the body of the article. When applying a template to an article, we will have to adapt those favorites to make them compatible with the new model.
3. To create links between articles, we will also need the encode the id of the target article in the body of the template. There can also be cyclical dependencies between articles which makes the creation of those articles difficult.

## Solution

This PR will turn the static templates of Knowledge into dynamic templates using QWeb.

The templates will now have a rendering context allowing people to define variables. The system will also expose functions that people can use to automatically convert id and fields based on the context being used.

task-3334717