This changes our approach to data validation. Before, we raised ValidationErrors at the moment of tax computation or EDI. In the worst case it would affect end customers viewing a record in the portal (which triggers tax computation automatically).

We now handle all errors not coming from Avatax through a new l10n_br_avatax_errors Json computed field [1]. It computes errors on the fly, and shows them to the user as they edit a sale order or invoice. Now users are immediately notified of missing configuration and issues. Most errors are actionable on top of that, leading to the exact record where they can fix the error. To help with this, two additional multi_edit list views were created to make it simple and clear what exact fields need to be corrected on product.product and res.partner.

Errors are considered blocking (must be fixed) through their level. Some of the errors we add are blocking because we know tax calculation or EDI would fail withouth them. Other ones won't block and will only produce a warning to notify the user of potential tax miscalculations.

On top of the transaction related validations described above, we also improve data validation before creating an Avalara account. This way the user doesn't need to interpret difficult to understand errors from Avalara's account creation API.

PS. the translations have been updated to a consistent width of 100 characters to optimize future translation changes.

task-4257672

[1] Inspired by l10n_ke_validation_message in l10n_ke_edi_oscu.

# TODO
- [x] Add translations to `pt_BR.po` files.

## Description
Following d6c6351c7f0b241578121d459943fdf2b305571e, the `ir.rule` related to discuss channels got more elaborated, with more subqueries. When loading an `avatar_128`, in an override of `_find_record_check_access`, a repetitive domain with an `any` operator on the same left leaf. This repetitive domain + the new `ir.rule` lead to a bad postgres plan, leading to a perf regression.

## Fix
We add an `auto_join=True` on `parent_channel_id` to avoid doing an additional nested sub-query coming from the `ir.rule`. This change is safe, as the comodel is the same model as the current one, and an user that has access to a subchannel, should probably already have access to its parent channel.
The other improvement is an optimistic early `super()` call, which should not raise any issue for internal employees, who already should have access to the avatar. In case of an access violation, we fallback on the previous behaviour.

## Benchmark
On a large database, loading an `avatar_128`, cache disabled in browser (simulating a first load) for an internal non-privileged user.

|                      | Timings   |
|----------------------|-----------|
| Before               | 300~400ms |
| `auto_join=True`     | 20~25ms   |
| + `super()` shortcut | 13~23ms   |

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