Follow the conventions of i18n by using one JSON per language

[AerunDev]

Description

This MR:

• Merge each JSON files into one JSON per language to follow i18n conventions.
• Prepare the migration to Weblate to ensure that the community can propose translation improvements as well as new localizations for the application.
• Add a new tool syncJson that ensures that translation files are perfectly aligned with en.json, with no obsolete keys.
  • Removes keys that are not present in en.json from translation files.
  • Preserves key order to match en.json.
  • Optimizes JSON file processing to prevent unnecessary writes.
• Close Follow the conventions of i18n by adding one JSON per language #369

Note before testing

• The assets/i18n/en.json file is now the unique source of truth now and will be used by Weblate to create any new language JSON file.
• For some languages localizations are not completed due to already outdated files. We'll let the community fix them using Weblate.

Warning

This PR brings breaking changes so we'll need to rebase the other PR.

Tests to perform

• The app runs properly in dev mode and release mode using npm run make.
• There is no regression or missing JSON key in the different UIs. If a key is missing you should see the key itself. I.e. "creature_name" instead of "Pokémon name".
• There is no typos or issues with the translations.

Next Steps

• The submission of texts on Weblate will be cleaned, and the JSON files retained from the merging of this PR will be used as the translation files.
• The CI processes will be adapted to retrieve updates and push them to the appropriate repositories.
  • Any modifications to the JSON files on the develop branch will be synchronized to Weblate.
  • Any updates made to translations on Weblate will be committed to specific branches that Weblate will open and maintain regularly (with a frequency to be defined). It will be up to us to review and manually approve the changes through the PRs opened by the Weblate account.
• Translation guidelines will need to be prepared on our side to specify translation rules (such as formatting with variables, key naming conventions, etc.).
• A communication will be prepared for the community members for a public release.
• Documentation will be provided later if needed, to avoid over-anticipating usage scenarios.

The goal is to make it easier for the community to manage translations while reducing the burden on developers.
Note that we will update the CI or adjust the processes based on actual usage to improve management.
Therefore, things might be a bit chaotic at first as we learn to manage the tool.