[IMP] documents improve search panel and home kanban view
This commits brings changes to the search panel that should improve UX:
- When coming from another app (e.g. Projects), the COMPANY folder
stays folded...
-... and the name of the folder containing the targeted document is
displayed below the breadcrumbs, right before the cogwheel.
- "Home" background changes when you hover or select it, the same way
as for the folders.
- Deselect 'Home'* (if selected) when adding a search item.
- Clear search and order by `last_accessed_date` when clicking on 'Home'.
- When users navigate through COMPANY folders via the Kanban or the List
view, and COMPANY is folded, the search panel does not expand the visited
folders.
- Clicking on the caret before the folder name, fold/unfold the folder
without selecting it (setting it as the active folder).
- Clicking on a folder name in the search panel just select it
(no folding/unfolding).
- Main folders like 'COMPANY', that name is preceded by an icon, also
have a caret for folding/unfolding.
- Kanban view: limit pager size to 40 records.

* actually, it's just a visual trick: removing the active class from the
'Home' header element.

task-4293935

Chat window have their style improved recently [1]: their size and aspect-ratio have changed. The aspect-ratio is intended for desktop use. In mobile, it should take whole height and width of screen.

This works well in almost all browsers: `w-100 h-100` seems to take precedence over explicit aspect-ratio. On Safari however, it seems to comply with given aspect-ratio even if this means cropping the content. This is unintentional and makes chat windows barely useable.

Steps to reproduce:

- Open a chat window with a relatively long conversation name on safari browser in small screen => The header content on the left is cropped.

This commit fixes the issue by putting the `aspect-ratio` in a non-mobile rule. That way `w-100 h-100` will be used correctly in Safari browser as in all other browsers.

[1]: https://github.com/odoo/odoo/pull/188665


Before / After
<img width="233" alt="Screenshot 2024-12-09 at 11 46 10" src="https://github.com/user-attachments/assets/b60a306d-1357-41cc-874e-da0529e40b4c"> <img width="233" alt="Screenshot 2024-12-09 at 11 46 32" src="https://github.com/user-attachments/assets/efd5a75a-73a8-4f79-b273-56516bd4996e">

**Problem**:
When creating a table and expanding its size, its position shifts upon reaching the window border due to the following code:
https://github.com/odoo/odoo/blob/1f4a85386eb258b08a3a6f43f1f3910598f005c4/addons/html_editor/static/src/core/overlay.js#L55-L57

The resize mechanism keeps the bottom of the table picker aligned with the top of the target element. When hovering over the gray square to add rows, the table expands upward (due to the position change), triggering a hover event again. This results in rapid row additions, causing the picker to jump back and forth, creating a poor user experience.

**Solution**:
Allow dynamic enabling or disabling of position changes during resizing, to match the fixed overlay positioning as prior versions (approved by the Product Owner).

**Steps to reproduce**:
1. Open the editor and insert a table.
2. Start adding rows by hovering over the table's resize picker.
3. As the picker moves above the target element, try to hover to add more rows.
4. Observe that rows are rapidly added during mouse movement, and the picker jumps back to the bottom, causing chaotic behavior.

opw-4351695

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

Before this commit, when the user creates a new billable project and change the order of the embedded actions inside the topbar of that project to put `Sales orders` embedded action first to be able to load that action first, the context of that embedded action is not given the `doAction` rpc and so the view loaded in the form view of SO to be able to create a new SO. The problem is if the user does not want to create a SO, it will not be able to change the first action to load for that project since the topbar is not visible in the form view.

This commit makes sure the context of the embedded action to load is given to `doAction` rpc.

Steps to reproduce the issue:
============================
1. Install Sales and project apps
2. Create new billable project
3. go inside that project to see the tasks of that project and open the top bar
4. display the `Sales Order` embedded actions inside the top bar of that project
5. reorder the embeddded actions inside the top bar to first load `Sales Order` action when we open that project.
6. Go back to the project kanban view
7. Click on that project

Expected Behavior
-----------------
The list view of sale.order model should be displayed

Current Behavior
----------------
The form view of sale.order model is opened to be able to create a new SO for that project.

task-4295738

**Current behavior:**
Having some embedded action for `documents.document` which has no `groups_ids` set will result in that action not ever appearing in the actions bar/menu in the documents app.

**Expected behavior:**
In the absence of any records in the `groups_ids` relation, the actions should be exposed globally.

**Steps to reproduce:**
*`-i documents_account` for example*
1. In technical settings, open the embedded actions list view

2. Edit the `Create Vendor Bill` action so that it has an empty `groups_ids` field

3. Open the documents app, click on the finance tab on the left sidebar

4. Click on one of the demo documents, observe in the actions menu for the record that the create vendor bill action is no longer present

**Cause of the issue:**
The domain was constructed incorrectly, as the
`('field', 'in', [False] + X.ids)`
pattern does not work when `'field'` is itself a m2m recordset.

**Fix:**
Split this domain leaf into 2 so we can check for membership as well as falsy-ness.

opw-4342841

When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is used to merge the account_move_line and account_analytic_line tables. This process takes an enormous amount of time on large databases and is unnecessary. Since this table is created whenever the analytic filters are changed (it is dropped on commit), it is much faster to only copy the relevant lines into the new table. This PR adds logic to identify the relevant analytic accounts for the given query, and changes the table-making query to only copy lines with the relevant analytic accounts attached to them.

Performance Benchmarks Pre:
| 100,000 lines | 250,000 lines| 500,000 lines|
|--------|--------|--------|
| 5.2s | 10.77s | 110s |
| 4.86s | 11.43s | 110s |
| 5.16s | 12.2s | 115s |

Performance Benchmarks Post:
| 100,000 lines | 250,000 lines | 500,000 lines |
|--------|--------|--------|
| 1.56s | 3.19s | 6.22s |
| 2.65s | 6.03s | 11.58s |
| 3.74s | 8.36s | 16.36s | 

OPW-4300365

### Steps to reproduce:
- Activate developer mode
- Install the 'l10n_ec' module and switch to an Ecuadorian company
- In Settings > Technical > Database Structure > Decimal Accuracy change the number of decimals for "Product Price" to 4 for example
- In Accounting, create a new Customer Invoice
- Select 'Instituto Ecuatoriano' as Customer
- Add a line with a price with 4 decimals
- Select 'Sin utilization del sistema financiero' as Payment Method
- Confirm
- On the blue popup at the top of the page, click 'process now' to get the XML in the chatter
- In the XML the "precioUnitario" field only has 2 precision digits, it has been rounded
- When adding a discount of 100% this field has all precision digits needed

### Cause:
The price_unit is calculated differently if the discount is 100%. The "precioUnitario" field should always have the number of precision digits specified in the settings.

### Solution:
We need to find the unit price without the discount, but without the included. This value is not computed.
As the values computed in the account.move.line are already rounded based on the currency (2 digits) we need to
recompute the values using `compute_all` and multiplying by the `price_digits` to not round in `compute_all`.

The way the rounding is made here is by taking the decimal precision from the settings and making it a power of 10 in `price_digits` (4 decimals results in price_digits = 10000). Then we compute the taxes with `price_unit * price_digits`. As, per definition,  `price_unit` has the number of digits used in the calculation of `price_digits`, we end up with an integer. But after the results of `compute_all` may no longer be an integer. We need an integer to keep the decimal precision. This is why, in the result, there is a call to `round()`.
The call to `float_round()` is to make sure there are not more decimals than 6. This is needed as the number displayed in the XML will always be of 6 decimals, so if the client set a number of decimals greater than 6, it will be rounded in the XML but not on the invoice. To ensure that both values are the same, we round the value here.

Some tests had "precioUnitario" with strange values that did not match the actual price_unit. It was because the precedent way to calculate this field was not perfect, I guess.

opw-4120341

Forward-Port-Of: odoo/enterprise#68555