Harmonize addresses management between portal & ecommerce.

Functional changes:

Portal users are now able to create and update their addresses on the portal.  Previously, they were only able to update their main account address through the /my/account route.

Now, the /my/addresses page allows portal users to create and edit their invoicing, delivery and 'other' addresses.

Technical changes:

1) Harmonization of addresses updates

The three routes of address updates (and flows) now follow the same unique API:

* /my/account (main account of portal users)
* /my/address (other addresses of portal users) (new route)
* /shop/address (customer addresses in the ecommerce checkout)

Same for the two routes handling the addresses display:

* /shop/checkout
* /my/addresses (new)

This allows the existing flow of addresses update on /my/account to benefit from the recent improvements done recently for the ecommerce addresses management:

* Form submission in js, with direct feedback without reloading the page
* performance improvements
* code quality improvements & cleanups
* strict checks and validation on the address values

2) Accounting localizations

Different localizations were extending the portal, ecommerce checkout (sometimes both) to allow customers to provide or update additional billing information on their account/addresses.

Now that the technical logic is shared between portal and ecommerce, most ecommerce localizations have been dropped, their logic moved to the base l10n module of their country.

Also, most south-american ecommerce localizations were replicating the same logic to handle Identification types. This logic is now mostly handled in the base l10n_latam_base module, simplifying the existing code and templates.

task-3628329

Backport of: https://github.com/odoo/odoo/pull/190312

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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