fix: Normalize literal before dayPeriod in formatToParts

[dklymenk]

Closes #7169

Node's and Chromium's formatToParts return NARROW NO-BREAK SPACE for the literal before dayPeriod. This causes hydration errors in Firefox and Safari, which use regular space for the same literal.

Since format returns regular space, it makes sense to standardize formatToParts to also use regular space.

I would've liked to refer to an issue in v8, but there was already one open and they claimed it's in-actionable for them. nodejs/node#49222

At present, it's not clear when Chromium and Node (if ever) are going to fix the inconsistency between formatToParts and format.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

[snowystinger]

Thanks for starting the PR, I think we have some more decisions to make.

[snowystinger]

TL;DR
I'm a little worried we're going to be playing whack-a-mole with this. I think it'd be better if we could somehow allow suppressHydrationWarning through or hold off rendering for a cycle on server and client when SSR.

Now on to findings:

Many countries prefer the non-breaking space https://www.stylemanual.gov.au/grammar-punctuation-and-conventions/numbers-and-measurements/dates-and-time
Across our supported locales:
In Chrome, it would appear that the non-breaking space char 8239 is the more commonly used.
In Safari, it's overwhelmingly char 32, except for ar-AE which uses char 160.
In Firefox, it's only char 32.

So I think we are ok to default it to 32 for now. But it looks like more than just Node is going to need a fix.

I got this from running the script provided in the issue

['ar-AE', 'bg-BG', 'cs-CZ', 'da-DK',
      'de-DE', 'el-GR', 'en-US', 'es-ES',
      'et-EE', 'fi-FI', 'fr-FR', 'he-IL',
      'hr-HR', 'it-IT', 'ja-JP', 'ko-KR',
      'lt-LT', 'lv-LV', 'nb-NO', 'nl-NL',
      'pl-PL', 'pt-BR', 'pt-PT', 'ro-RO',
      'ru-RU', 'sk-SK', 'sl-SI', 'sr-SP',
      'sv-SE', 'tr-TR', 'uk-UA', 'zh-CN',
      'zh-TW'].map((locale) => {
const formatter = new Intl.DateTimeFormat(locale, { timeStyle: 'long', hour12: true });
const segments = formatter.formatToParts(new Date())
const secondsSegmentIndex = segments.findIndex(segment => segment.type === 'dayPeriod');
          if (secondsSegmentIndex > 0) {
    return segments[secondsSegmentIndex-1].value.charCodeAt(0);
          }
          return 'not used'
})

This should be tested across every locale we support. I also noticed that the test uses timeStyle short, but the example script used long. We would also need to use hour12: true in the options since many locales default to a 24hr representation.
Something along these lines with the right assertions (not just a non-null check).

  it.each(['ar-AE', 'bg-BG', 'cs-CZ', 'da-DK',
    'de-DE', 'el-GR', 'en-US', 'es-ES',
    'et-EE', 'fi-FI', 'fr-FR', 'he-IL',
    'hr-HR', 'it-IT', 'ja-JP', 'ko-KR',
    'lt-LT', 'lv-LV', 'nb-NO', 'nl-NL',
    'pl-PL', 'pt-BR', 'pt-PT', 'ro-RO',
    'ru-RU', 'sk-SK', 'sl-SI', 'sr-SP',
    'sv-SE', 'tr-TR', 'uk-UA', 'zh-CN',
    'zh-TW'])('should format to parts with space as literal before am/pm', function (locale) {
      let formatter = new DateFormatter(locale, {timeStyle: 'short', hour12: true});
      console.log(locale, formatter.formatToParts(new Date(2020, 1, 3, 13, 0)));
      expect(formatter.formatToParts(new Date(2020, 1, 3, 13, 0))).not.toBeNull();

      let formatter2 = new DateFormatter(locale, {timeStyle: 'long', hour12: true});
      console.log(locale, formatter2.formatToParts(new Date(2020, 1, 3, 13, 0)));
      expect(formatter2.formatToParts(new Date(2020, 1, 3, 13, 0))).not.toBeNull();

      let formatter3 = new DateFormatter(locale, {dateStyle: 'full', timeStyle: 'long', hour12: true});
      console.log(locale, formatter3.formatToParts(new Date(2020, 1, 3, 13, 0)));
      expect(formatter3.formatToParts(new Date(2020, 1, 3, 13, 0))).not.toBeNull();
    });

Good news, it doesn't crash in locales such as zh-TW which actually places the dayPeriod first

    zh-TW [
      { type: 'dayPeriod', value: '下午' },
      { type: 'hour', value: '1' },
      { type: 'literal', value: ':' },
      { type: 'minute', value: '00' },
      { type: 'literal', value: ':' },
      { type: 'second', value: '00' },
      { type: 'literal', value: ' [' },
      { type: 'timeZoneName', value: 'GMT+11' },
      { type: 'literal', value: ']' }
    ]

However, while testing, I ran into an issue ines-ES where the space is inside the dayPeriod itself in addition to outside. In Node, Chrome, and Firefox it's 160, and in Safari it's 32

const formatter = new Intl.DateTimeFormat('es-ES', { timeStyle: 'long', hour12: true });
const segments = formatter.formatToParts(new Date())
console.log(segments[6].value.charCodeAt(2));