Allow storing telephone number in E164 format

Problem/Motivation

One of the biggest challenges with the current Telephone module is that it's just a glorified textfield. It has no option to normalize the telephone number - either for the purpose of validation or formatting.

In Commerce applications, we see more and more requirements from payment gateways to collect and pass the telephone number to the payment gateway during Checkout. Given we have payment gateways from all over the world, supporting customers in virtually every possible market, we also must be able to process and send the phone number in a normalized way.

Fortunately, 2 standards are leading here:
- E.164 - the international public telecommunication numbering plan
- national format - popular if only supporting customers in one market

Google came up with the library that is now an unofficial standard, that allows transitions between formats as well as data validation. In PHP it was adapted as-is and released as a standalone composer library.

Drupal Contribs such as telephone_validation and telephone_formatter modules utilize said library to perform certain operations on the user input. But the problem is - we don't have a common storage where telephone could be stored in a normalized format, similar to how numbers or dates are already handled by core. With the steady growth in the usage of said modules and surpass of 10k installation I feel it's time to have better support directly in Core.

Proposed resolution

- Create a new field type plugin in the telephone module - TelephoneE164Item (telephone_e164). Allow users to choose that field type over current, simplified TelephoneItem
- Store the phone number user input AND E164 version in the database
- Create a validation constraint that will only accept the value IF user input can be represented in E164 format
- Create a formatter(s?) to show the value directly from user input, in E164 format, international or national format.

Remaining tasks

- Find out what should be the schema for the new field
- Document when the old field type should be used over the new field type (alarm numbers, vanity phone numbers, etc.

User interface changes

n/a

Introduced terminology

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet