Datetime date from CLDR data

[sven-oly]

Ready for review.

[sven-oly]

I need some help converting these date/time data into UTC "Z" format. Then we can compute the offset seconds too!

Right now, testing this in ICU75 causes all ICU4C, ICU4J and NodeJS tests to fail or have errors.

[sven-oly]

Note that the CLDR expected test results may be incorrect in some cases:

1. date/time styles full/full have "at" between the date and time output in ICU4C. The expected result isn't correct.

Expected: July 2, 2001, 5:44:15 PM GMT+4:30
Actual: July 2, 2001 at 5:44:15 PM GMT+4:30

{
"dateLength": "long",
"calendar": "gregorian",
"locale": "en-US",
"input": "2001-07-02T17:44:15+04:30[Asia/Tehran]",
"expected": "July 2, 2001, 5:44:15 PM GMT+4:30"
},

2. In some cases , there's GMT in the expected
   March 7, 2024, 11:30:01 AM GMT+3:30
   March 7, 2024 at 11:30 AM

{
"dateLength": "long",
"calendar": "gregorian",
"locale": "en-US",
"input": "2024-03-07T11:30:01+03:30[Asia/Tehran]",
"expected": "March 7, 2024, 11:30:01 AM GMT+3:30"
},

{
"timeLength": "long",
"calendar": "gregorian",
"locale": "en-US",
"input": "2024-03-07T11:30:01+03:30[Asia/Tehran]",
"expected": "March 7, 2024, 11:30:01 AM GMT+3:30"
},

[sven-oly]

This now uses simple logic to identify the "known issue" of " at" replacing "," in some cases. Similarly, some other substitutions are caught.

Note also that the test data shows an ASCII comma as expected instead of the Arabic comma. These show up as test failures, but maybe it's a bug in the CLDR data.

[sffc]

This is a much more complicated known-issue catcher than I was expecting. I was expecting that we would put a blanket "known issue" on all failing inputs where the dateTimeFormatType is "standard".

[sven-oly]

OK, I'll take a look at the failures to see if this will capture the substitution of "," with " at" and similar replacements in other languages.