Move away from counterpart

### Your use case

We'd like to move away from using counterpart for i18n, because:
* It's had no release for 8 years
* It depends on node libraries that need to be polyfilled which conflicts with storybook's vitest testing
* There are now libraries that do proper i18n

We're mostly considering react-intl, as it's what other Element projects use and known to be fairly robust and maintained.

Things to consider:
* react-intl uses a context to provide the IntlShape object. It's assumed you put the context provider at the root of your app, although we have dialogs & context menus that mount at the root of the dom so we need more than one context provider to cover everything.
* We would probably want to make it work through our current i18n module although the interface is slightly different
* Does it need to be blocked on changing all the call sites of _t in Element Web to use the i18n module?
* Can react-intl's babel translation scanner be adapted to look for a call to a different function than `intl.formatMessage`?
* What exactly is the process in Localazy for changing the format of our translation files, and do we need to do this all in the same change?

Current notes:
react-intl creates a fresh IntlShape object whenever anything changes, eg. the app language, so we would need to use `createIntl` each time, with a fixed cache from `createIntlCache`.

### Have you considered any alternatives?

_No response_

### Additional context

_No response_