i18n: Add a caching layer to i18n-calypso numberFormat to improve performance

[chriskmnds]

Fixes https://github.com/Automattic/i18n-issues/issues/926

Proposed Changes

This is a follow-up to #98405 (comment) where we introduce Intl.NumberFormat to i18n-calypso's numberFormat method. In this PR we cache the Intl.NumberFormat instance to avoid recreating on every call, which may be arbitrarily large due to components rerendering or just general use in the app. For the most part, usage-wise, the formatter is created with the same options.

The idea I am exploring is to not checklist the Intl.NumberFormat options to a selected few, but rather create the index/cache from arbitrary options. Two strategies in this PR:

1. A map with straight-forward use of json.stringify on the options passed.
2. A custom solution with some potential improvements (a nested map on locale first, options next). We can expand on this if we need improvements over json.stringify.

Benchmark

I've added some plain comparison tests in the form of a Jest suite. It compares simple use with a static set of options across 100K or so iterations. The results that I get, probably consistently:

1. json.stringify fastest with ~201
2. custom approach second with ~220
3. no caching last with ~2245

So we get a whopping 10x performance improvement with a bit of caching. json.stringify seems most straight forward with lest complexity.

Why are these changes being made?

Improve numberFormat (our go-to number formatter)

Testing Instructions

• Code review
• Run the benchmark tests with yarn test-packages -- packages/i18n-calypso

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Link to live branch is being generated...
Please wait a few minutes and refresh this page.

[chriskmnds]

Obviously, this is not mergeable. We can tweak the strategy and tests until we are confident, then I'll do the necessary cleanup / remove tests etc.