Internationalisation (i18n)

### Summary
There's a growing need for our components to be compatible with different languages. As part of this work, we need to test our components for min and max content, where a translation could affect the reflow of our components.

### 💬 Description
This work will likely follow a method similar to our dark mode approach. At a component-level, we will need to ensure that a locale can be set on each component. Other design systems, such as Cloudscape, have made use of an app-level internationalisation (i18n) provider to set the locale across all components, which is a method we should consider. Setting locale at either component-level or app-level should affect in-built text such as button labels and calendar day names. For our date-time components, locale should affect the default first day of the week, weekend days, an outputted date string, numbers used for date/times etc. Please note, this list is not exhaustive.

As this work is expansive, it may be easier to begin with the Romance languages; French, Spanish, Catalan, Italian, Portuguese and Romanian; as well as some of the most prevalent West Germanic languages; German, Dutch.

The current proposed method is to create a JSON dictionary file for each of our supported languages. Our components should also allow users to pass in their own JSON dictionary files for languages we are not yet able to support.

### 💰 User value
This will allow our components to be usable with different languages. It will also make way for right-to-left (RTL) support.

### 📚 User Stories
If relevant, describe the high-level functionality as user stories.

*As an* ICDS user:
*I need* to create an app that adapts to my users' preferred language
*So that* my audience have an equal experience in my app, despite what language my app is in

Start by reviewing the component-level and app-level internationalisation approaches described in the issue, using the existing dark mode approach as a comparison. Define the supported-language JSON dictionaries, custom dictionary input, locale effects on built-in text and date-time components, and min/max content reflow tests before implementation.

Written by the indexing model from the issue text.