Make default banana-checker configuration more suitable to MediaWiki extensions & skins

[legoktm]

For most MediaWiki extensions, we currently parse extension.json to get the value of MessagesDirs, and then pass that onto banana-checker. I think we should move this logic into banana-checker itself, which provides the following benefits:

• If there's a JSON error, eslint can report it before banana fails on it
• Properly check that manifest_version is 1 or 2 before parsing (current behavior is liable to break if a hypothetical 3 comes out, albeit very unlikely)
• Avoid use of Object.assign that eslint complains about (example).

I don't know if we're ok with an implicit/magic read from extension.json or skin.json if it exists, or whether we'd have an explicit options: { from: 'extension.json' } or something...either would be fine IMO.

[Krinkle]

I'd rather not hardcoded for MW specifically, but I think there's a simpler way that meets our needs.

We can point banana-checker directly at i18n/. There's generally only one such directory anyway. We can have it crawl subdirectories and treat those as their own message domain as well. And we could support an array (JS) and/or multiple variadic arguments (CLI) for when they reside in entirely distinct top-level directories (e.g. not just i18n/foo and i18n/bar, but i18n/ and foobar/i18n).

Avoid use of Object.assign that eslint complains about

It complains because someone's misconfigured ESLint on that file. This method isn't available in ES6, and in that repo the file is declared as running in ES6 or later.

[legoktm]

Uh, that's perfect. Even just adding recursive support would be good enough. I checked through all of Gerrit and the only repos that don't have all the i18n in one top-level folder are:

• MediaWiki core (special anyways, doesn't use extension.json)
• UniversalLanguageSelector, which has i18n/ and lib/jquery.uls/i18n/
• VisualEditor, has i18n/ and lib/ve/i18n/
• DonationInterface, which has <component>/i18n/. Reversing it to i18n/<component>/ should be straightforward.

So yes, if we recurse through the configured directory and default it to i18n/ that would take care of 99% of our repos.