Extract all strings, use gettext-like strategy for l10n

[zepheiryan]

Extract all of the strings sitting around in various code files. Replace with a gettext-like strategy (any libraries?) so English strings can be keys for their localized translations and stand in as the default value.

[zepheiryan]

There are a number of matters to address in pursuing this.

1. Add a parameter-based method of setting the page's preferred locale. The methods surrounding locale deal solely with ways to force one locale at all times or to let the client decide; the page that's actually serving the Exhibit should have an opportunity to weigh in.
2. Add getters and setters for finding out what the server, Exhibit default, and user agent preferred locales are and which one is actually in operation.
3. Once the locale to use is determined, load the Exhibit default and increasingly specific locales depending on the client. E.g., if the user-agent is using pt-BR, load default, pt, and pt-BR (given they all exist). Lookup in decreasing specificity / preference: pt-BR, pt, and finally the default, which will be en.
4. Restructure so l10n lookup is a key-based hash table instead of the objects with some constants and some methods strategy now in play.
5. Rewrite locales to reside in one JSON file. Eliminate the need to structure and load the locales as modules, loading just the JSON file. Likely eliminate the need to bundle them. Rewrite methods as sprintf statements where appropriate, move complex methods into util/ miscellaneous files when needed.
6. Note to localization authors that a missing key will allow for gracefully degrading, but an empty string will get used as-is.

[zepheiryan]

For developers, call with Exhibit._(key, arg1, arg2, ...); for example, Exhibit._("%general.badJsonMessage", url, errorType)

[zepheiryan]

There are a couple non-string entries in the localization hashes that I've left alone to ease this transition; they may need to be modified or excised at a later time. Some entries are booleans, arrays, or HTML templates - the HTML is somewhat understandable; in an RTL language, the tags should be rearranged. It is a bit off to have it in there, but it will stay for now.

[zepheiryan]

While this feature is implemented, there is another somewhat bland task to be done of translating all of the existing locales into the new system. There's a record of progress in the wiki, under the comparison to earlier versions.