Add support for translating text in Rust code in combination with translation bundling, without gettext as run-time library

[tronical]

Feature Description

Objective: Develop an application with Rust and Slint, where some of the strings to translate are located in .slint files and some strings are in .rs files. The application is to be deployed with bundled translations as a Rust binary.

Acceptance criteria: The ability to meet the objective with the help of documentation, features in Slint, and possibly external crates. A run-time dependency of the application binary to the libintl library must not be required, neither through dynamic or static linkage.

This contributes to #3715

Product Impact

No response

[tronical]

The proposed path forward would be at least three-fold:

1. Add the ability to include additional message catalogues in the bundled translations. This might require a new variant of the with_bundled_translations functions.
2. Change the generated code to also permit (internally) a lookup of a translation by source string, not just index. (note: we should avoid duplicating strings here; ideally the rust compiler does that for us)
3. Add public API to permit users to translate a string, with arguments. This means making a variant of fn translate( original: &str, contextid: &str, domain: &str, arguments: &(impl FormatArgs + ?Sized), n: i32, plural: &str, ) -> SharedString public.

Users can then either call these functions directly, or (more likely) use the tr crate to annotate strings and provide a Translator adapter that maps to the Slint function to look up the translation.

[ogoffart]

3. Add public API to permit users to translate a string, with arguments. This means making a variant of fn translate( original: &str, contextid: &str, domain: &str, arguments: &(impl FormatArgs + ?Sized), n: i32, plural: &str, ) -> SharedString public.

I think we probably want a lower level function:
fn lookup_translation(msgid: &str, contextid: &str, domain: &str, n: Option<i32>) -> SharedString
which doesn't contain the arguments. (not sure about the plural)
and also not sure about the return type. ideally we can return a &'static str, but maybe that's not possible (but ideally SharedString could contain a &'static str)

[tronical]

Agreed. I think this is the right signature.

For SharedString: I agree. I think if we're willing to sacrifice a bit SharedVectorHeader this should be doable.