Propose new Mautic features

Has your proposal been discussed on the Mautic Forums already?
https://forum.mautic.org/t/use-a-coherent-county-list-with-iso-abbreviations-in-db/10816

Is your feature request related to a problem? Please describe.
It is very challenging to add a contact or company via API including a full address, because if country and state fields are not an exact match according to the Mautic regions definitions, the request gets rejected. As an aggravating factor, naming conventions on both country and region definitions are inconsistent, and regions of several countries are incomplete or outdated. Those issues are surely affecting geolocalization as well, since an exact match can hardly be guaranteed under such circumstances.

Describe the solution you'd like

I would propose:

1. To find an authoritative source like the CLDR charts and update the whole file countries.json and regions.json accordingly:
   https://www.unicode.org/cldr/charts/45/by_type/index.html
   I am not sure if CLDR is the best authoritative source, but it is surely a good option. If anybody can suggest something better, please comment. Probably there is a way to even extract this information programmatically. A good option might be this libary, that provides already correct data as a PHP implementation:
   https://github.com/commerceguys/addressing
   It would be interesting to also investigate, which standards the geolocalization services are using to deliver country and state information.
   I am aware that updating this definitions will require a database update, but it is better to do that once well done then to have 100 pull requests, because somebody is accidentally stepping over a wrong definition that they happened to find.
2. To change those definitions to include a key/value pair, so that a two letter country code is associated to the country name, and the sames for the region definitions. Having this information, we could extend the API to accept in the country field the two letter code or the written out country name, and the same for the state definitions. Using the above library would resolve this problem as well.
3. As a next step it can be even considered to save the two letter code instead of the name in the database. This would save some space, and would reduce also the number of database updates in case of name changes. I am not much familiar with Symphony, but I assume that such a change can be done just on the model layer, without the View and Logic being aware of any change in the database.
   
   For migration purposes we need to do a matching of the current definitions with the new values, which can probably be assisted by AI.