Form and kanban view archs are compiled into owl templates. Those archs are translated server-side, before being sent to the client. They can contain `t-translation` directives (typically ="off" to disable translations). This tells the view processing in python not to translate the subtree.

In the js compilers, that attribute is listed among the tolerated attributes for kanban archs, but not for forms. However, the cases are similar, so their should be not differences between the two.

Moreover, since [1], compiled templates are wrapped into a
```xml
<t t-translation="off"/>
```
node, s.t. terms aren't translated twice (once in python, and once in js, by owl).

Instead of tolerating the `t-translation` directive in form view, this commit ignores it in all view compilers. This directive indeed makes sense, so it is valid to use it in kanban and form archs (then used by the view processing in python). But the view compilers in js must ignore it, so we simply remove it.

[1] odoo/odoo#158759
Fixes runbot error-134670

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/89a327918 [REL] 18.0.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/fb8e860ce [PERF] tokenize: faster space tokenize [Task: 4684215](https://www.odoo.com/odoo/2328/tasks/4684215)
https://github.com/odoo/o-spreadsheet/commit/5f3b8913e [REF] tokenize: extract new line tokenize [Task: 4684215](https://www.odoo.com/odoo/2328/tasks/4684215)
https://github.com/odoo/o-spreadsheet/commit/fb9699125 [FIX] pivot: make pivot update notification sticky [Task: 4680152](https://www.odoo.com/odoo/2328/tasks/4680152)
https://github.com/odoo/o-spreadsheet/commit/d584b7d07 [FIX] pivot: measure input badly colored when in error [Task: 4677359](https://www.odoo.com/odoo/2328/tasks/4677359)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce:
- Install stock, stock_account, sales
- Create a product with pricing policy not standard(AVCO, FIFO)
- Track this product by lot and keep lot valuation **unchecked**
- Add a quant of the product with this lot
- Create a quotation on the product and confirm the SO
- Confirm the delivery
- Activate the lot valuation on the product
- Make a return delivery based on the delivery we had
- Confirm the return

**Issue**:
Traceback is thrown
```py
new_std_price = ((amount_unit * qty_avail) + (move_cost[lot] * qty)) / (qty_avail + qty)
KeyError: stock.lot(55,)
```
Because `move_cost` is a dictionary returned by `_get_price_unit()`, which gets the current lots’ valuations. Since the pick is a return one, then `_get_price_unit()` uses the original pick stock valuation layers and hence we were disabling the valuation on the original delivery then the layers don’t have the lot of the product valuated. Then the `move_cost` dict is not having the lot of the product while valuating it currently, hence the KeyError is thrown. This issue happens with the AVCO, FIFO because both valuation models depend on the already valuated lots values using the `_get_price_unit()`.

**FIX**:
Ensure `_get_price_unit()` properly handles cases where lot valuation was disabled at the time of the original move but is enabled later by adding lots of the return pick if not included in the valuation layers of original pick.

opw-4662744
opw-4660094

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

### Steps to reproduce:

ISSUE 1:

- Insert multiple icons (e.g., /image, icon) into a paragraph.
- Place the cursor before the first icon.
- Press the right arrow key, and notice that the selection jumps to the second paragraph, skipping over the icons.

ISSUE 2:

- Create three paragraphs.
- Insert icons into the second paragraph.
- Place the cursor in the first or third paragraph and press the up/down arrow key it skips the second paragraph.
- Set up following HTML:
```html
<p><br></p>
<p><br><span class="fa fa-glass"></span>[]</p>
```
- Press arrow up key.
- Cursor will move to the first paragraph.

### Description of the issue/feature this PR addresses:

- Pressing arrow key (left or right) caused the cursor to consecutively skip over all icons until a text node was reached.
- Pressing up/down arrow keys would skip sibling block containing only icons.
- Pressing the up/down arrow keys would skip over icons in the same block if the cursor is on a `<br>`.

### Desired behavior after PR is merged:

- Add extra `\uFEFF` before and after icons to prevent them from being skipped.

task-3045033

…mesheet

**Issue**
In a subscription, the qty delivered of a SOL with "Prepaid" invoicing policy
wasn't updated when timesheets were added.

**Steps to reproduce**
1. Have a service subscription product with an invoicing policy "Prepaid/Fixed
price" and creating a task on order.
2. Create a monthly subscription with a start date 15 days in the past
3. Add some timesheet hours on the task.
4. Run the "Subscription: generate recurring invoices" cron.
- Actual: quantity delivered on the SOL stays at 0.
- Expected: timesheet hours falling during the subscription period are added
to the delivered quantity of the line.

**Cause**
Commit https://github.com/odoo/enterprise/commit/a6420bdacab3b9c9f440f48db3b442e6b6c7b655 added a new module overwriting
the computation of the delivered quantitiy for recurring lines based on
timesheets, for products with an invoicing policy `delivered_timesheet`.
However, the computation is overriden for all timesheet lines selected by
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L11-L12

A second filtering is applied later
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L21
Which exluces products with an invoicing policy different than
`delivered_timesheet`

**Solution**
For products with a "prepaid" invoicing policy, compute the delivered
quantities the same way: the timesheets delivered during the subscription
period.
Note that as explained in a comment, `Side effect: It won't work for the
first period if the invoice cron never run. (the next invoice date has never
been incremented)`

opw-4509495

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings, activate "SEPA Direct Debit (SDD)"
- Create a contact:
  * Country: Belgium
  * Bank Account: [a Belgian IBAN]
- Go to "Accounting / Customers / Direct Debit Mandates"
- Create a mandate for the created contact
- Validate the mandate
- Create an invoice for the created contact as customer
- Confirm the invoice
- Pay the invoice with "SEPA Direct Debit"
- Print the invoice

**Issue:**
The information explaining that the invoice has been paid using direct debit and that the invoice should not be paid manually is not printed on the invoice.

**Cause:**
This information is printed if "sdd_mandate_id" field of the invoice is set.
"sdd_mandate_id" is a related field to "origin_payment_id.sdd_mandate_id" field.
However, since the refactoring on "account.payment", "origin_payment_id" is not set on an invoice anymore.
It is just set on the journal entry linked to a payment.
Therefore, we cannot rely on that field anymore to print the SDD mandate payment information.

**Solution:**
The "matched_payment_ids" field can be used instead.
It's a Many2many field referring all payments linked to the invoice.
If one of these payments has "sdd_mandate_id" set, the SDD mandate payment information is printed on the invoice.

opw-4672191