Remove non-default locales from the repo

[olizilla]

We should remove all the locale files from the repo and and them to the .gitignore, and update the docs and run scripts to fetch them on postinstall.

Having generated artefacts in a repo always leads to trouble eventually, and in this case it sets us up to waste the time of people who volunteer to fix translation issues.

See #950

[lidel]

@olizilla removing locales from repo will introduce various issues. I am against mainly for two reasons:

1. Builds are no longer reproducible in offline mode + require access to the internet and Transifex API
   • Third party web service can break our builds
   • Also, I am not sure if you can fetch locales without account on Transifex and API key in ~/.transifexrc, which complicates CI and local setups for drive-by contributors
2. We will be getting an amazing improvement for translations soon, but it needs locales to be present in repos (added you to email thread with Transifex, tl;dr is in Transifex: Improved GitHub Integration  ipfs-shipyard/i18n#5)

To avoid people submitting PRs with translations, we could:

• put copy/link from ipfs/i18n#how-can-i-contribute-translation-for-my-language in public/locales/README.md or public/locales/READ_THIS_BEFORE_TRANSLATING.md
• create PR template with checklist and add an item "I am aware that translations should be submited via https://www.transifex.com/ipfs/public/ instead of creating a PR"

[lidel]

Also, I suggest we always close PRs that bypass Transifex (eg. #950 - should close without merging).

Gently thank for translation and ask them to apply changes via Transifex or just link to ipfs/i18n#how-can-i-contribute-translation-for-my-language

• Example: update zh_CN ipfs-companion#658
• Why? This creates a paper trail that future translators can discover while doing research before submiting PR. So not only informs the author of the current PR, but also people that could do similar thing in the future, but look for examples of previous PRs before creating their own.