Issue:

- DATEV does not support multiple foreign currencies on a single journal line.
- This can occur when reconciling a bank transaction where:
  - the payer uses one currency (C1),
  - the bank journal is held in another currency (C2),
  - the company uses a third currency (C3).
- The existing export logic could not represent the bank liquidity and
  foreign AR/AP currencies separately in such cases.

Fix:

- Detect 3-currency cases from bank statement transactions and their
  liquidity line.
- Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the
  transaction into two logical legs:
  - Bank → Clearing (bank journal currency)
  - AR/AP → Clearing (payer currency)
- Emit the liquidity leg only once when multiple foreign AR/AP lines are
  reconciled against the same bank transaction.
- Keep regular 1- and 2-currency transactions on the existing export path.

Impact:

- Correctly represents 3-currency bank settlements in DATEV.
- Keeps each exported line in a single foreign currency.
- Leaves manual entries and payment transactions outside this specific
  handling, as the scenario is specific to the bank liquidity line.

taskID-5457547

### Steps to reproduce issue:

1. Activate the Mexican localization and configure a company able to sign
2. Create an invoice with one line: a product with a valid UNSPSC code,
   Price 250.00, VAT 16%, Discount 99.99%
3. Confirm, then Send & Print with the CFDI checked
4. In the generated XML, the following values are off:
    - In node "Comprobante": SubTotal="200.00" Descuento="199.98"
    - In node "Concepto": ValorUnitario="200.00" Importe="200.00"
      Descuento="199.98"
    - Expected are 250.00 and 249.98

### Explanation:

`discount` is a Float(digits=(16, 2)) and both conversions of the field don't give the same float: `convert_to_column` writes it as '99.99' while `convert_to_cache` rounds it to 99.99000000000001. Hence, 250 * (1 - 99.99000000000001 / 100) = 0.0249999999999695, rounded to 0.02, but 250 * (1 - 99.99 / 100) = 0.0250000000000250, rounded to 0.03. `price_subtotal` is therefore stored as 0.02 when the invoice is posted, while any later request, such as the one generating the CFDI, recomputes 0.03.

`gross_price_subtotal` is computed by dividing the rounded `price_subtotal` by `discount_factor`, which amplifies the rounding error of `price_subtotal` by 1 / discount_factor, so 10 000 times with a 99.99% discount: 0.02 / 0.0001 = 200.00 instead of 250.00. That difference is exactly half a cent, which is also the tolerance of the condition added by 771d3e3cf, so the condition fails and the amount computed from `price_subtotal` wins over `price_unit`. Every price whose net lands on a half cent is affected, i.e. the odd multiples of 50 with a 99.99% discount.

### Fix reasoning:

`price_unit` is the source of truth for `ValorUnitario`. Tolerating one rounding unit instead of half of one is enough to cover the rounding of `price_subtotal`, so `price_unit` keeps the priority. The fallback still applies to the cases it was added for, where something other than the discount affects `price_subtotal` (e.g. price-included taxes), since those differ by much more than one rounding unit. The discount amount is derived from the gross, so it absorbs the difference: `Importe` - `Descuento` still gives `price_subtotal` and the total of the document is unchanged.

ticket-id: [6386895](https://www.odoo.com/odoo/project/49/tasks/6386895)