[Translation] Add lint:translations command

[Kocal]

Q	A
Branch?	7.2
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	Fix #...
License	MIT

Hi everyone (cc @welcoMattic),

This PR adds a new command lint:translations in the Translator component, which lints the translations like lint:yaml could lint Yaml files, lint:templates lints Twig files, etc...

Why?
Our application uses translations from Lokalise. They are contributed by non-tech users and sometimes they can contains issues (missing }, missing other in plural, etc...).
Thoses issues results in a error 500 because the ICU translations can not be correctly parsed, and we want to prevent this by linting the translations before deploying (if the command fails, we don't deploy, and we don't have errors 500).

The current approach is a bit naive, at the moment it simply call TranslatorInterface#trans() and catch exceptions (if any), but it can be improved in the future.

PS: During the time between creating the command and opening the PR, we used it on our app and we were able to detect 5/6 invalid translations :)

WDYT? Thanks :)

---

Also, quick question, how do Symfony/PHP developers deals with trim_trailing_whitespace = true from the .editorconfig, and asserting on the Console output (which contains trailing spaces)?
Do they disable EditorConfig in their IDE? Thanks!

EDIT: I don't have the issue anymore by right-trailing white chars for each lines, but I'm still curious :)

[Kocal]

Fabbot has some issues with the license header in tests files, if I keep it then Coding Standard fails, but if I remove it then License Headers fails. :/

EDIT: ok that's fine now, I guess that was due to the declare(strict_types=1) that I've removed.

[Zombaya]

As a symfony-user, not a symfony-contributor, this looks very useful to me and something we would like to use ourselves. There can never be too many lint-commands to be used in CI 🙂

[fabpot]

LGTM, but with a few minor comments.

[fabpot]

Thank you @Kocal.

[stof]

InputOption::VALUE_OPTIONAL does not make sense here IMO. This would allow passing the option as bin/console lint:translations --locales, without passing a value for it.
Making the value of an option optional is a rare case and is not what you want in most commands.

Also, I think locale would be a better name for the option as lint:translations --locale fr --locale en makes more sense than lint:translations --locales fr --locales en (InputOption::VALUE_IS_ARRAY works by repeating the option in the command, but each occurrence provides a single value)