Allow retrieval from languageHashes using environment in order to side-load i18n assets without rebuilding the application

[mahnkong]

The i18n assets are currently built into the application at compile-time, so a translation change in any of the ".json5' files requires a rebuild of the application. We are maintaining our translations since DSpace6 using a CSV format for easy editing, and for dspace-angular we adapted the process to generate the '.json5' files as well as the compressed json files as required. These assets (browser and server) are side-loaded into the dspace-angular container using volume mounts. So, if it would be possible to configure the actual languageHases during startup no rebuild of the application would be necessary, allowing to stage translations by anyone with ease.

This could be achieved by introducing a configuration to the instance's config.yaml:

languageHashes:
  - lang: de
    md5: 0fd7b78448093f8ce05fd9bd4f1edc83
  - lang: en
    md5: 4ed2840c555bc6830fceaf517b2bfbda

In our case, a modified entrypoint would iterate over the side-loaded i18n assets and create the .yaml accordingly. (this is not part of the issue, as this entrypoint modification will depend on how someone passes the assets into the container)

The code inside the angular application must be changed to also consider the environment for obtaining the languageHashes instead of only considering the process.env.languageHash variable prepared by webpack.

[mahnkong]

The PR was updated to cover the comment of @tdonohue regarding the ideal scenario of treating the languageHashes.

Now the "languageHashes" environment key is populated during server startup, but only if the angular server process has the environment variable DSPACE_DYNAMIC_LANGUAGE_HASHES set and it's value is set to be true. This ensures the correct files are loaded without the need of manually changing any configuration files.