Steps to reproduce:

- Open Firefox.
- Type a few characters.
- Add a space after the characters.
- Press backspace.
- Observe that both the space and the last visible character are removed.

Description of the issue/feature this PR addresses:

- In Chrome, pressing space inserts a `&nbsp` (non-breaking space, `U+00A0`), which is treated as a visible character by `isVisibleChar`. Thus, only the whitespace is removed when backspace is pressed.

- In Firefox, pressing space inserts a regular space (`U+0020`), which `isVisibleChar` identifies as invisible. As a result, the backspace action incorrectly calculates the range and removes both the space and the preceding character.

Character details:

- Chrome: `char.charCodeAt(0).toString(16)` → `U+00A0`
- Firefox: `char.charCodeAt(0).toString(16)` → `U+0020`

Desired behavior after PR is merged:

- In Firefox, pressing backspace after a whitespace removes only the invisible character without affecting the preceding visible character.

task-4363847

Problem
---------
1 - Open Odoo 18.0
2 - install l10n_hu_edi
3 - switch to "HU Company"
4 - create an outgoing normal invoice with other than HUF currency
5 - put items, taxes, select partner, etc.
6 - print the invoice
-> KeyError: 'formatted_total_vat_amount_in_huf'

The issue occurs because, in multi-currency, the method
`_l10n_hu_get_invoice_totals_for_report` is expected to add
`total_vat_amount_in_huf` to the tax dictionary as required by the 
invoice template.

However, currently, the said method only adds `total_vat_amount_in_huf`
for credit notes / refunds, in other cases, it stops early and does not
add the required key-value pair in the dictionary.

Solution
---------
Make sure the method always adds `total_vat_amount_in_huf` to the tax
dictionary, while making sure that it only reverses the tax values when
it is rendering a credit note / refund like before.

task-4391659

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

Versions
--------
- 18.0+

Steps
-----
1. Go to eCommerce;
2. go to a product with attributes;
3. open the editor;
4. set specification to display in accordion;
5. enable "Compare" option on Cart.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> TypeError: tuple indices must be integers or slices, not product.public.category
> Template: website_sale_comparison.specifications_table

Cause
-----
The `categories` value set in this template contains an ordered dict with `product.attribute.category` records as keys, and `product.template.attribute.line` records as values.

When inserting its logic into the `website_sale` template, its variable name conlficts with the `categories` value returned by the `WebsiteSale` controller, which contains `product.public.category` records.

The issue occurs when it tries to use a `product.attribute.category` record to index a `product.public.category` recordset.

Solution
--------
Rename the `categories` variable to `attrib_categories` in the `website_sale_comparison` template.

opw-4356669

In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.:

```
Charleston Co Educational Capital Improvements Tax (Special) at 1%
Charleston Co Tt (Special) at 1%
```

But `find_or_create_tax()` maps both of them to SC SPECIAL 1%.

This doesn't cause issues for invoice_line_ids, those amounts are correct. But the journal items are not because there's only one tax journal item for this tax and its summary total gets overwritten instead of added to. This leads to the total on the invoice not matching the sum of debits/credits in the journal items tab.

Fix it by adding to the summary total instead of overwriting it.

PS. An alternative solution is to create unique tax names by incorporating the jurisCode and possibly other relevant fields. This approach would enhance the accuracy of tax representation on invoices. However, historically, we have prioritized brevity over accuracy [1].

[1] https://github.com/odoo/enterprise/pull/68549