update and clean up i18next implementation

[scheidtdav]

Description

Revisit how i18next should be installed in a react-router application according to the project thats officially linked on the i18next website.

The aforementioned project links the old way of doing it that we currently deploy. Parts of that are deprecated by now though.

In addition to upgrading, this feature should make sure that the users locale setting is respected.
The propose middleware in the linked project should load the user locale from the database to achieve that.

Language changes can be instant when the local state is also updated.

Use case

Once logged in, users will immediately have the app in their preferred language, no matter the browser setting.
Developers benefit from a streamlined translation api thats simple to use and available to all components.

Implementation ideas (optional)

The server should most likely be the leading element of this.
This implies:

1. When a user is logged in, the users language setting is used
2. When no user is logged in, the Accept-Language header sent by the browser (aka the browser language) is used
3. If the browser language is not supported, the fallback language set on the server (english in our case) is used

The client should almost always follow the setting of the server.
The only exemption is probably when the language is changed on the client. Ideally this shouldn't trigger a page reload and instead should modify the i18n instance on the client while also changing the preference in the user profile. That way the new language is set "instantly" and when the user refreshes the implications outlined above still result in the same update language.

Additional information (optional)

The project describes several ways of storing the language setting to communicate between client and server.
I don't quite understand why it needs to store the language on both the html tag and in a Cookie. If the cookie may be prevented, thats probably good.