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.