Add tests to Intl.DateTimeFormat and Intl.RelativeTimeFormat for various numbering systems

[ben-allen]

Previously there was a spec bug: the Intl.NumberFormats created within Intl.DateTimeFormat.prototype.format and Intl.RelativeTimeFormat constructor were not passed the numbering system to be used.

See tc39/ecma402#919
Fix #4260

[ben-allen]

Updated tests to be slightly less "golden string" -- instead of checking for exact match between formatted string and expected string, now expected is a substring without whitespace, and test is for whether formatted string includes the expected substring.

[ptomato]

Thanks! Your effort in using fewer "golden strings" is appreciated.

[ptomato]

I'm not sure about this, but I think you need to include en-US-u-nu-arab and the others in this list as well.

[ptomato]

Ditto.

[ptomato]

Unlike the previous test, you might actually be able to make this one even less "golden", with something like

const expected = new Intl.NumberFormat(locale).format(seconds);

[ben-allen]

updated!

[iamstolis]

I find it problematic/incorrect that the expectedTwoDigit result of en-US-u-nu-hanidec ends with AM. Not only this is inconsistent with other expected results (that do not contain this suffix despite the actual format contains it most likely) but the space before AM in the expected string is U+0020 Space while ICU/CLDR suggests U+202F Narrow No-Break Space. While the suggestion of U+202F is a bit controversial and some engines decided not to follow it (see, for example, these lines in V8), this test should not prefer the engines that do so.

[ptomato]

@iamstolis Could you open a new issue for that? The comment is likely to get lost on a merged PR.

It's an ongoing effort to remove "golden output" like " AM" from the test262 corpus. See #3786.