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.

[sven-oly]

Categorize failing date time tests with 'dateTimeFormatType" == 'standard' to be a "Known Issue".

[sven-oly]

Ready for another look!

[sven-oly]

This classifies most of the date time format problems as "known issue" except for the different beween ASCII comma and arabic comma.