Discuss sidebar feels too crowded, and items take too much space.
This commit makes slight adjustments to make it look nicer:

1. discuss Expand/Collapse icon replaced by "..." clickable dropdown
   - motivation: this looks consistent with chat window options, prevent accidental click, and allow to put more options in the future. Also the button looks more like an "options" button
2. sidebar items are smaller in height but wider
   - motivation: more efficient spacing which looks better
3. mailboxes are significantly smaller in height
   - motivation: some users do not use mailboxes so less presence is appreciate for them. Besides, they don't need big size of avatar so they can be smaller without much compromise
4. category names are smaller and muted
   - motivation: they looked too alike to channel items, so this put more distinctive style making less exhausting to use Discuss app
5. category and channel actions are circle buttons, so it looks nice inside square on hovered/active items. Also less opacity so they are less distracting in general
6. active navigable list item is easier to see (colorful rather than greyish)
7. Unread threads are more visible (bolder text)

Before
<img width="1281" alt="Screenshot 2024-09-29 at 16 57 36" src="https://github.com/user-attachments/assets/88ead9ab-ea2d-44bb-a9c1-762d88050e92">

After
<img width="1282" alt="Screenshot 2024-09-30 at 13 29 36" src="https://github.com/user-attachments/assets/97cd2513-d84e-408a-ad78-9d3da57cb977">

Since Knowledge is being refactored to use the new editor features, notably
embedded components, which are the successor of knowledge "Behaviors", it is the 
perfect opportunity to move some of them in the html_editor module, so that any 
HtmlField can make use of them.

### Table of Content

This embedded component dynamically aggregates headers in a HtmlField value and 
displays an anchor tree redirecting to each header by clicking on it. 

### Video (Iframe)

This embedded component stores the URL of a trusted video provider (like
youtube), and displays an iframe in the HtmlField when it is mounted.

### Excalidraw (Iframe)

This embedded component stores the URL of an excalidraw drawing boad, and 
displays an iframe in the HtmlField when it is mounted.

### File

This embedded component stores data related to an existing attachment and 
displays it in the HtmlField, with useful features like opening the FileViewer,
and download the file. The file can be renamed (locally for the HtmlField,
independently of the real attachment name).

This PR also introduces fixes and improvements related embedded components and
knowledge needs.

See each commit for more details.

Enterprise: https://github.com/odoo/enterprise/pull/67083

task-3672747

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Adrien Schoffeniels <adsc@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>

The creation of tax lines is made with 2 duplicated mechanisms:
_get_generation_dict_from_base_line is the method saying the granularity of your tax lines.
This method is used by everyone using the compute_taxes method.
Since V16, a custom similar mechanism has been duplicated on invoices in _compute_all_tax in account_move_line.py
=> We should have only one mechanism.

Then, another problem is the whole logic to compute the round_globally is wrong.

Instead of:
- compute the tax values per grouping key per tax repartition line per line
- aggregate the amounts
- round

we should:
- compute the tax values per tax and per line
- round
- dispatch the amounts to the repartition lines.

Let's take some examples:
Suppose 3 lines of:
price_unit = 33.33, tax = 10%
price_unit = 33.33, tax = 10%
price_unit = 33.34, tax = 10%

Using round_per_line, each line will compute 3.33 as tax so a total of 9.99.
Using round_globally, each line will respectively compute a tax amount of 3.333, 3.333, 3.334 so
a total of 10.0.
However, depending the current grouping key to compute the tax lines (each one corresponding to a
repartition line), the computation could be different.
Suppose the analytic checkbox is ticked on the tax and the base lines are:
price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_A
price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_B
price_unit = 33.34, tax = 10%, analytic_distribution = 100% on account_C

In this specific case, the total of taxes will be 3 x 3.33 = 9.99 because it will generate 3
tax lines, one for each analytic distribution.

Another problem is when dealing with price included taxes.
Suppose two lines:
price_unit = 21.53, tax = 21% incl
price_unit = 21.53, tax = 21% incl

Each line will compute a tax excluded amount of round(21.53 / 1.21) = 17.79
So the total untaxed amount is computed as 17.79 x 2 = 35.58.
However, since the tax is included in price, the untaxed amount should be
round(21.53 * 2 / 1.21) = 35.59
It means there is 0.01 that need to be distributed on invoice's journal items.

task-id: 3725705