Switch to a simple gettext l10n system

[ChristophWurst]

This seems like a trivial change. But it took me ages to figure out. Anyway …

What it does is

• Use a getttext-based translation approach, just like we use in other Nextcloud code
• Have a script that extracts the strings (no more fragile php script)
• Is able to just read the raw .pot files
• Bundle translations statically (no dynamic import necessary. overhead minimal due to low number of strings)
• Dynamically decide which locale to use (based on Nextcloud's locale or 'en')

For technical reasons I had to switch from a simple Babel+Typescript system to one with Webpack in order to do the locale bundling. This also forced me to switch from Jest to Mochapack. But that works just as fine. The tests here are trivial.

Once https://docs.transifex.com/transifex-github-integrations/github-tx-ui is set up (having my fingers crossed that this actually works), I'll add some integration tests for different locales. But manually adding an en.pot allowed me to test translation successfully.

@nextcloud/javascript please have a look. I would like to use this approach for https://github.com/nextcloud/nextcloud-vue as well.

Fixes #1

[nickvergessen]

You ment to make us all review this not work on it, right?

[ChristophWurst]

You ment to make us all review this not work on it, right?

I meant to have you work on the review :)

[juliusknorr]

Shouldn't we use the language settings for this instead of the locale setting?

[ChristophWurst]

I'm never sure. @nickvergessen knows best

[nickvergessen]

Well see nextcloud/server#14784

So moment JS is actually "fucked up" as it has only one option to set this and is unable to handle a locale being different from the language.

[juliusknorr]

OK, then it should be fine for now otherwise it would just be the "seconds" which would be in the proper language, the rest provided by moment would have the language defined by the locale.