feat: allow custom languages in `IntlProvider`

[Benehiko]

Adds custom language support to the IntlProvider. This allows users of ory/elements to specify and provide their own custom translations without needing to add it to the ory/elements repository.

Related Issue or Design Document

Checklist

• [ ] I have read the contributing guidelines and signed the CLA.
• [ ] I have referenced an issue containing the design document if my change introduces a new feature.
• [ ] I have read the security policy.
• [ ] I confirm that this pull request does not address a security vulnerability. If this pull request addresses a security vulnerability, I confirm that I got approval (please contact security@ory.sh) from the maintainers to push the changes.
• [ ] I have added tests that prove my fix is effective or that my feature works.
• [ ] I have added the necessary documentation within the code base (if appropriate).

Further comments

[Benehiko]

This is already possible & documented:

https://github.com/ory/elements/blob/4bdbac1033af756d1986df67f808cd0228a7a44d/README.md?plain=1#L359-L377

We could improve the docs to show how the default translations can be extended instead:

import { IntlProvider } from "react-intl"
import { locales } from "@ory/elements"

const customMessages = {
  ...locales,
  de: {
    ...locales.de,
    "login.title": "Login",
  },
}

const Main = () => {
  return (
    <IntlProvider locale={customMessageLocale} messages={customMessages}>
      <Router>
        <Route path="/" component={Dashboard} />
        {/* ... */}
      </Router>
    </IntlProvider>
  )
}

I agree that we do support it, but it requires the user implementing the library to directly use react-intl.

In an optimal path scenario I can see more users wanting to only use a copy paste example with defaults and the option to override some labels, such as the login ID -> Email for example.

The path to reach this use case in the current method isn't as obvious and a bit confusing, especially if you have no idea which keys do what. What if we introduce breaking changes later on inside the translations? or special formatting like we do here https://github.com/ory/elements/blob/main/src/react-components/provider.tsx#L50-L52

I'm not against the current way and I think supporting it makes sense to give users a choice and the ability to customize the translation layer themselves. But a happy path must exist and i don't think the current implementation is that happy path.