[FIX] base, tools: fix the behaviour of inline translated elements
Steps to reproduce:

- Go to a website page (in "Edit" mode) > Add a "Title" snippet.

- Select the whole "title" > Set a highlight effect on it.

- With the same text selected, transform it to a link and save.

- Try to translate the title into another language in the editor > You
cannot update the text or remove it.

The code from [1] introduced a feature that allows forcing some specific
elements to be "translated inline" using the `o_translate_inline` class.

It was used mainly to handle specific cases where elements DOM is
handled in JS in a way that breaks the "Translate" editor (e.g., text
highlights).

By forcing the highlight `<span/>`s to be inline translated, the fix
from [1] only handled situations where a highlight effect has a non-
"inline-translated" element (e.g., a link) amongst its text content.

E.g. This DOM structure:

```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
    Go to the <a href="/contactus">Contact Us</a> page
</span>
```

Which caused the translation `<span/>` to be set inside the highlight
structure [A].

Now, as explained in the steps above, there are some cases like with
this DOM:

```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
    <a href="/contactus">Contact Us</a>
</span>
```

That will make the translation code check the inner non-"inline
translated" children even within a `o_translate_inline` parent (see:
`translate_xml_node()` > `hastext()` | `process()`), leading to the
same issue as [A].

The goal of this commit is to prevent any similar situation causing the
translation spans to be added inside elements forced to be translated
as a whole, by automatically considering all elements inside a
`o_translate_inline` parent as inline translated too.

This commit also adds a test for the explained behavior.

[1]: https://github.com/odoo/odoo/commit/e9659e55356e5e4de63f2324eb88a7b6f07cd835

opw-4243639

linked to: opw-3980975
linked to: opw-4089482
linked to: opw-4061566

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1] and [2], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

These checks are intentionally implemented in both modules because they apply
at different stages and for different providers:
1) `l10n_co_dian`
When `DIAN: Free service` is selected as the `Electronic Invoicing Provider`
from the `Invoicing Settings`, the date constraint is evaluated at `send time`.
After the invoice is created, the validation is performed when the user sends 
the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the 
invoice date is outside the allowed range.

2) `l10n_co_edi`
When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same 
rule is checked `at the confirmation time` of the draft invoice. In this case, 
the validation results in a `chatter message`, not a blocking send-time error.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [3].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679

[2]:
https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028