Refactor many more translations

What does this MR do?

Basically does most of the heavy UI lifting for &7 (closed):

• implement translator member as part of several parent classes
• refactor a great deal of 'old' translations to translator
• actually translate a great deal of previously hardcoded strings too
• while at it: touch up lots of embedded frontend code
• while at it: refactor hard-to-read PHP code into something more clear (at least to me, ymmv)

Some areas were left untouched for reasons:

• Store* because I'm still hoping we will pick up !1469 (closed) soon-ish where I already did most of that work
• Settings* because I have a feeling these screens might end up in Vue soon anyways
• parts of some Xhr stuff because I felt indifferent about them and/or they're not used often

You'll need to review this commit-by-commit. I can split the MR into multiple smaller ones if you'd like, but they would need to be processed in order, since conflicts in the translation files are not fun to resolve (trust me).

How confident are you it won't break things if deployed?

Since I went through this on a file-by-file basis (more or less) I was able to test the affected complex of functions and then move on.
This doesn't ensure that there are no bugs (there will definitely be bugs in a changeset of this magnitude), but I'm more confident that nothing broke horribly than I otherwise would be after having turned over 4000 lines in almost 150 files.

I opted for cleaning up / refactoring PHP as part of the translation changes because I was having a hard time "ignoring" the dirt after the first few. It's not ideal, but I had the best intentions and I'm hoping that reviewing this PR commit-by-commit is still somewhat possible as a result.

Links to related issues

• &7 (closed)

How to test

Basically look for broken code or broken translation strings. Everywhere. Sorry, this one is harder to test 😄
You can go through individual commits and see if some of those areas interest you, checking particular user clickpaths or function calls there.

Checklist

• added a test, or explain why one is not needed/possible...
• no unrelated changes
• asked someone for a code review
• set a "for:" label to indicate who will be affected by this change
• use "state:" labels to track this MR's state until it was beta tested
• added an entry to CHANGELOG.md
• add a short text that can be used in the release notes
• Once your MR has been merged, you are responsible to create a testing issue in Beta Testing Repo:
  • Consider writing a detailed description in German.
  • Describe in a few sentences, what should be tested from a user perspective.
  • Also mention different settings (e.g. different browsers, roles, ...). how this change can be tested.
  • Be aware, that also non technical people should understand.