Allow user customization of the presentation order of fields of postal addresses

Feature request: Allow customization of the presentation order of fields of addresses

The order of elements in the ADR field of a vCard is fixed by RFC 6350, but the order of fields in a written postal address varies by locality. For example, many european countries (e.g. FR, DE) place the postal code before the city name (U.S. and vCard standard is to place the postal code after the state/province).
(See UPU standard S42 for the gory specifics).

Example:

123 High Street
San Francisco, CA 94114
USA

vs

27 RUE PASTEUR 
14390 CABOURG 
FRANCE

The RFC allows a properly presented postal address to be included in the ADR. LABEL:

 ADR;LABEL="Mr. John Q. Public, Esq.\n
      Mail Drop: TNE QB\n123 Main Street\nAny Town, CA  91921-1234\n
      U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.

If the contact list and calendar don't need the individual ADR components, it would be preferable to let the user type in a freeform text label when entering a contact address, and do away with the individual components altogether.

For comparison: I think contact lists like Google Contacts parse user-provided address text in a sophisticated way to extract the components, but NextCloud may be able to just leave them blank. Roundcube lets the sysadmin configure an HTML template (e.g. for Europe, '{street}<br/>{locality} {zipcode}<br/>{country} {region}') into which fields get stuffed, and adjusts the order of the input fields to match the order of the fields in the template. Of course that approach is broken when the user wants to enter an address for a country that uses an address template different from that in the system template.

This issue affects data entry and presentation of contacts on the contact detail page, and also the autocompletion of nextcloud calendar event locations, and the presentation in IMip invite email. (There may be other places postal addresses are presented).

This was brought up and discussed previously in nextcloud/calendar#933.

Start by tracing the contact data-entry and detail-page address presentation, calendar event-location autocompletion, and IMIP invite email rendering named in the issue; no files or tests are identified. Define the supported customization model and verify that address ordering and freeform labels work consistently across those surfaces and localities.