Improve the display of the tax details in the journal audit report.

A few issues were spotted:
* The header of the "Taxes Applied" table was not covering the full width when there are taxes related to multiple countries, fixed by using the right variable in the `colspan`
* When taxes have long names, which happens easily with OSS etc, they were displayed on multiple lines in the table, making the table very long. This is fixed with the new `.name` css class, wrapping the line with an ellipsis.
* When there are taxes related to multiple countries, the full name of the country was used. Since the vertical space is scarce, we display the country code instead.
* A lot of space was wasted with poor usage of table elements.
  - The sub-tables were defined inside of `td` elements with fixed `colspan`. This doesn't make sense as they have nothing to do with the headers. By using a single `td` using the full width of the table, and splitting the tables inside of a flex element, we are now more free to have tables of different width depending  on the content of the sub tables
  - The sub tables were using `table-layout: fixed` for no apparent reason. This is forcing thin columns (i.e. the country code) to take a lot of space, and making larger (larger amounts) columns overflow.

[REV] account_iso20022: Wrong XML generated for Switzerland

This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da.

This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt.

The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix.

ticket-4535542

=======================

[FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file

https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard.

Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file.

ticket-4535542

Forward-Port-Of: odoo/enterprise#99150
Forward-Port-Of: odoo/enterprise#98918

Currently an error occurs when user tries to activate a stripe card.

Steps to replicate:
- Install `hr_expense_stripe_demo`, `l10n_be`, and `hr_payroll` with demo data.
- Use ngrok to portforward localhost to the public internet and open the link.
- Switch to My Belgian Company.
- `Settings > Expenses > Expense Card > Agree to T&C > Save > Click Connect`.
- Select `Use Test Phone Number > Use Test Code > Save For Later`.
- Create a new Employee named `Test` and click `Create User` (provide an email).
- Under the `Personal` tab, set the value for the `Payslip Language` field.
- Go to `Expenses > Cards > New`, assign Cardholder as `Test`, and save.
- Click `Activate`, fill in the required fields, and save.
- The error will appear.

Error:
`KeyError: False`

Cause:
- The error occurs because line [1] attempts to remove the `False` item from the `preferred_langs` OrderedSet.
- Line [1] was added as a guard to remove any `False` value from `preferred_langs`, this occurs when an employee has no language set and hence it will be assigned as False.
- However, if the employee has a language selected, there is no `False` value in the `preferred_langs` set, causing line [1] to raise a `KeyError: False`.

Solution:
- Using the python method `discard()`, we can safely remove any False value and function wont raise any error if False is not found in the `preferred_langs` OrderedSet.

[1]: https://github.com/odoo/enterprise/blob/e1d8b1316ce822055a1b42c7f5893cfd1a3dd8a5/hr_expense_stripe/wizard/hr_expense_stripe_cardholder_wizard.py#L176

sentry-6975780020

Forward-Port-Of: odoo/enterprise#98216