Draft: Introduce org.kde.i18n QML module as a replacement for context properties

It was not clear how should we proceed w.r.t. auto-magic translation domain deduction.

• It would be convenient not to pass a domain into every function call, but then it would be impossible to use a singleton.
• It would be possible to have a non-singleton with translationDomain property, but then consumers would have to pass it around into sub-components (possible but painful) or create multiple instances (not so efficient), and either way the domain would have to be known to QML.
• Maybe instances or attached objects could pull domain out of QML engine just like Kirigami.Theme does? Translation domain is constant so it doesn't have to be an observable property. And there is a trick to return one and the same object as an attached property for all attached object requests within the same context, making the type essentially a context-scoped singleton. But the downside is that attached properties can not be implemented in QML, so they won't be able to bind to locale at runtime (abusing void expression).
• Maybe it is possible to combine the two approaches to dynamically create a pure QML object (which binds on locale) and return it as an attached object?

Well, hopefully this patch answers all those questions at once!