Support multiple languages for the interface

There's a bunch of relevant context in [the corresponding BlueOS issue](https://github.com/bluerobotics/BlueOS/issues/1937#issue-1836245867).

This is even more important for Cockpit than BlueOS, since it's intended to be the main way people will frequently interact with the vehicle, and operators without English as their primary language could react faster and more effectively to notifications in their native language (generally a vehicle only needs to be _configured_ infrequently). Cockpit's interface also has significantly fewer text elements than the BlueOS one (especially since it's still in early days), so could serve as a small-scale testing ground for different approaches, before applying the most effective and maintainable one to BlueOS.

It would be a valuable selling-point to have this at or soon after Cockpit's official launch, to prove we're serious about accessibility and that we're confident Cockpit will be used at scale around the world. It's not critical to have many languages implemented immediately, but having the functionality available to do so sends a powerful message.

I'm currently thinking:
- Support for different languages is likely best handled through independent [add-ons/plugins/mods](https://github.com/bluerobotics/BlueOS/issues/1939) (rather than having a single "translations" file that tries to do all non-English languages)
- This makes it easier to contribute a new translation language, and easier to see which ones are already available
- All interface text should be possible to replace, but a translation file should not need to be complete to function
- i.e. a translation file that only translates button labels should still work
- Hopefully we can make a tool of some sort to generate text that should be translated for a given system, and flag text that isn't being translated by any available translation files (both online in the registry (for developers), and locally in a vehicle (for users))
- Longer term it'd be useful to provide an online tool that allows people to submit translations to prompts, without even needing to manually create and upload a translation file by themselves
- Ideally we could search the ArduPilot (and PX4?) codebase for status text messages to provide source text for translation, that can be detected and swapped out live before display and TTS
- As a bit of fun / as an illustrative example we could use this to implement a "pirate" language
- The same "swapping" system could be used to add icons for different status priority levels and notification types as well (e.g. ⚠️‼️💦)
- We might need some kind of ordering variable/parameter or mechanism for translation files, because augmentations will likely be designed to operate on the original text, and should happen before other translations
- There needs to be some way for a widget to either provide translations or be included in a translation file
- This could get messy, and needs some thought
- My current best idea is for the store to support sub-groups of linked extensions/add-ons, such that a widget could present itself as a cockpit add-on, and a translation could present itself as an add-on for that particular widget
- It may be helpful to refer to [QGC's approach](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/settings_view/general.html)
- Note that this includes unit settings that apply to mission planning and telemetry and the like

Start by reading the linked BlueOS issue #1937, the add-ons/plugins discussion in BlueOS issue #1939, and QGroundControl's approach referenced in this issue. The body proposes several possible translation systems but names no Cockpit files, tests, entry points, or agreed completion criteria.

Written by the indexing model from the issue text.