Add i18n support

[finnp]

This PR adds the possibility to overwrite the English default Strings as requested in #6. The developer can pass an i18n object as an option mapping langage keys to alternative represenations (see /lib/en.json for english defaults). I didn't offer i18n support for strings that definetely seemed to be for developers only.

Also there is a new usage key which can be passed a readable stream providing an alternative usage template.

I used the visualwidth module to assure that it works for chinese character, too. However for chinese to fully work in adventure, terminal-menu has to be fixed (possibly with this https://github.com/substack/terminal-menu/pull/16)

[martinheidegger]

Regarding the i18n support. For the workshopper I used (my) i18n-core module that offers basic but relevant features like symbol replacements, fallback mechanisms, composite options and plurals. Perhaps its worth considering it.

[tdd]

I intend to work on a branch this week that should use the same i18n behavior as workshopper, and submit that. This would help translators not juggle two distinct behavior sets across workshoppers.

Does that sound like something you'd be interested in?

Also, re: terminal-menu: it also completely breaks on lowercase diacritics (e.g. 'é'), which are super-common in, say, French, Spanish and Italian, to name only these. This does need fixing, haven't gotten around to it yet. Doesn't help that most workshoppers use an old terminal-menu though (new one still has issues on this, btw).

[martinheidegger]

Probably this problem? tokuhirom/visualwidth-js#4

[tdd]

Sounds likely, indeed. Reminds me that terminal-menu invokes visualwidth.width with a second arg at true, apparently for terminal mode (your code, right?) but the used module (0.0.1) does not feature a second parameter, as it was apparently not published to npm yet…

Not even sure that change fixes the issue, too.