Merge back the product translations

[lslezak]

Problem

• The product translations need to be merged back to the original YAML files
• We cannot store the translations in Agama because in theory there might be external (3rd party) product definitions so the translations needs to be included in the product YAML file
• Related to Generate and upload the product POT file to allow translating the product descriptions #851

Solution

• Read the translations from the PO files and and merge them back to the original YAML product files
• Implement a GitHub Action which regularly opens a pull request with updated translations (similar to the current solution with the web frontend translations)

Notes

• Originally I wanted to use keys like description-cs, description-de,... for the translations, but then the translations could be scattered over the whole file (the order is not guaranteed or forced)
• So use a new translations key with a reference to the original key:

  description: "Original description ...."
  translations:
    description:
      cs: "Czech translation..."
      de: "German translation ..."
      es: "Spanish translation ..."

  This also allows translating some other keys if needed in the future.
• When changing the original description the translations need to be manually deleted because they would not match the original text anymore. If we forget that the next run of this GitHub Action will remove them anyway (or update with the new translations if they are already available) . So accidental invalid translations should not stay here for too long.

Testing

• Tested manually with provided Czech product translations
• See a testing GitHub Action run
• And the PR created with the new translations

[lslezak]

A fix for the previous PR, it turned out that the month (and only the month!!) starts from zero.

[lslezak]

Explicitly adding an empty translations key. Otherwise the script would add it at the end of the file and it is better to have the translations close to the original text.

[coveralls]

coverage: 75.063%. remained the same
when pulling 08961a1 on lslezak:master
into 6ae6d69 on openSUSE:master.