Add some support for internationalization to the route system

[toolness]

This adds some support for internationalization, using Django's built-in support for it, along with some bespoke code for managing locale-prefixed routes in our front-end JS.

A new ENABLE_I18N environment variable, which defaults to false, now controls whether internationalization is enabled.

If enabled, non-localized paths will automatically be localized, e.g. / will redirect to /en/ (since that's the only language we support right now). This is done via Django's i18n_patterns().

This PR does not add support for actually localizing content on the JS side. We're still exploring various solutions for that--see #12 for more details.

That said, this PR does add some minor localization: since the GraphQL endpoint is now internationalized, generic form validation errors that are coming from core Django, like "This field is required", will be translated to the current locale, which is nice.

To do

• Add an ENABLE_I18N setting to enable internationalization.
• At present, definitive django-handled 404s in our letter and hp action routes get redirected to locale-prefixed routes, which is rather annoying. It might just be easier to have those be locale-prefixed to begin with, so that this doesn't happen, and so we can eventually localize those routes if it's beneficial to do so. We're just prefixing all our hp and loc routes with the locale, so 404s will 404.
• We should probably locale-prefix the GraphQL route since it delivers human-readable form errors to users, and the locale-prefixing should make the localization "just work".
• Currently, the letter of complaint renderer is localized, which doesn't mean much for most of the content because we haven't internationalized it; but we do display the date via Django's template system, and that is localized. We should probably explicitly set the locale to English when rendering the letter, since we don't want to have all-English letters with Spanish dates in them.
• Remove duplicate auto-locale-prefix-redirection code in the JS side, since Django's i18n_patterns() does this automatically for us.