Add linting support for i18next

[zoran995]

What this PR does

Added "i18next/no-literal-string" rule to lint rules for .js and .jsx files, and extracted some of the strings to the translation.json. Lint support for i18next is added using eslint-plugin-i18next dependency. It would be nice to merge this as soon as possible, so there is no double work later. Some basic details about this are introduced in #4227

Checklist

• There are unit tests to verify my changes are correct or unit tests aren't applicable (if so, write quick reason why unit tests don't exist)
• no tests
• I've updated CHANGES.md with what I changed.

[soyarsauce]

@steve9164 what do you think about this?

I lean in favour of it given how much the i18n has progressed in terriajs now, however bits of it goes against the philosophy of avoiding using "disable-next-line" - although one could argue it's cleaner in certain scenarios rather than using // eslint-disable-line i18next/no-literal-string on an already long row of code.

Given that, it's not as severe for that particular case as accidentally disabling linting for a string if prettier re-flows code in the same way that it may for types.

[tephenavies]

Thanks for the PR.

I think it's a good idea. We really need a complete overhaul of our eslint config though. There are some modifications here that seem unnecessary given the eslint rules (inconsistent application ignoring of "use strict";, ignoring strings in require which I think can be avoided by further adjusting config).

Also there are many merge conflicts.

Before anybody puts further effort into this we should decide when we are going to prioritise fixing up eslint. See also #3303.

[zoran995]

This has been stale for too long; the only way to get this is to redo the work.