New and Unified Translation System

[St0rml]

This PR introduces a new and unified translation. The system utilizes .toml files which are defined per template and contain all strings which need to be translated. The common/lang.typ provides the heart of this translation system: The function

/// Retrieve translation strings from .toml file by key
///
/// - key (str): key identifiying the string
/// -> String in the locale of the document
#let lang(key) = {...}

This function retrieves the relevant string from the .toml file and returns the value in the correct language based on the text context. While this is not ideal for overhead, it is quite simple and intuitive in my opinion.

The .toml files are structured like so:

languages = ["en", "de"]

[translations]
task.en = "Task"
task.de = "Aufgabe"

• The first entry defines the languages which are available for this template. This is utilized in the function check-locale of lang.typ, which should be called after a template is instantiated to check whether the user-given language is supported by the ´translations.toml´ file of this template
• The table [translations] holds all translations identified by key.language-code. By design of TOML, no duplicated keys can be created here, preventing mistakes for longer tables.

This branch is based on #21

[Rdeisenroth]

The Toml is structured weirdly imo, would it not be better to have the toml structured like:

# translations
[en]
date = "date"
pointsingle = "point"
pointplural = "points"
# ...
[de]
date = "Datum"
pointsingle = "Punkt"
pointplural = "Punkte"

This way it would be easier to add a new language (and producing cleaner diffs). And you wouldn't have to specify an array of available languages. Then we could also make en the default, and always fallback to that, if no translation for one word in a language is given

[JeyRunner]

@St0rml I think this is a good idea, but I support @Rdeisenroth argument that the toml structure could be improved (@Rdeisenroth proposed structure would be a good fit for this).