[core] fix(NumericInput): improve performance on Firefox (#5466)

[PetrusAsikainen]

Fixes #5466

Checklist

• Includes tests: passes existing tests, no functionality changes
• Update documentation: no functionality changes

Changes proposed in this pull request:

Number.prototype.toLocaleString is relatively slow on Firefox, and is currently heavily used by NumericInput.getDerivedStateFromProps (which further calls isFloatingPointNumericCharacter on each character of the current value). This means that if you have a bunch of NumericInputs on a form, it slows renders down to a crawl even if the NumericInput isn't being updated itself.

This PR improves the situation in two ways:

• Caches the regexes generated by isFloatingPointNumericCharacter per locale. I don't think there's a reasonable situation where the representation of numbers would change during page load.
• Only calls roundAndClampValue when necessary in getDerivedStateFromProps - essentially, moves the computation of sanitizedValue within the if statement it's used in.

You can see the difference in this Codepen (try using Firefox): https://codesandbox.io/p/devbox/condescending-vaughan-qysyk7

Reviewers should focus on:

Whether this changes behavior in any way.

I'm not sure whether Map is in the current "browser support level" of Blueprint, but its only use in the repo is uniqueId which NumericInput also uses, so I assumed it's fine.

[changelog-app]

Generate changelog in packages/core/changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

[core] fix(NumericInput): improve performance on Firefox (#5466)

Check the box to generate changelog(s)

• Generate changelog entry