Better translation handling

With this PR, we discard the old Dojo (nls) mechanism for translations, and use our own which works both internally with WebODF ("Unknown User", "Loading...") and with application UI strings. The new translations are English -> Other Language mappings in files like `editor/translations/de-DE.json`.

Consider programs/editor a 3rd-party app. A consumer will implement translations in roughly the way it does:

The Editor app has an accompanying mechanism to choose the locale and accordingly download the JSON file for that locale's translations. When the translator function implemented by the editor (`editorTranslator.translate`) is ready with it's dictionary, we can feed this function to `runtime.setTranslator()`. All subsequent translations within the editor and within webodf will simply be done by invoking `runtime.tr("English String")`. We may also extend `runtime` with methods like `runtime.translateContent`, which goes and calls `runtime.tr` on all children of the provided node which possess `data-i18n` attributes. Of course, such extensions will only be usable within your own application.

Any strings which have no corresponding translations will be shown in their original English text.

Note that the everything starting `Editor` class entry point does not depend at all on the custom translator. Only the `localeditor.js` and `collabeditor.js` files do. Therefore, anyone wishing to use our Editor but also desirous of using their own translation mechanism/dictionaries (even for internal WebODF strings) will not need to make any changes to the `Editor` or to WebODF.