First pass at implementing site locales and translations

[jaredcwhite]

Partially addresses #49

This PR adds two new concepts to Bridgetown:

• Available locales. You can now add an available_locales key to your config to list one or more locales (en, fr, zh, etc.) OOTB it's "en". Bridgetown will configure the I18n gem with those locales and to look for YAML files in src/_locales, so you can add translation files just like you would in a Rails app.
• Current locale. A site always has a current locale, configured either by the BRIDGETOWN_LOCALE environment variable if present or the default_locale config key. You can access this value in templates via site.locale, and in Ruby code (plugins, etc.) you can switch the current site locale via site.locale = :de.

It also adds a t helper for ERB/etc. templates and a t Liquid tag. The Liquid tag is currently very basic so it doesn't support default values, interpolation, etc. The ERB/etc. helper just aliases I18n.t so you get the full power of that method.

I think this is a good start to adding multilingual site support. Theoretically, just this functionality could let you write a script to build a site multiple times, each with a different BRIDGETOWN_LOCALE env var and destination folder, and then you'd get multiple sites that have different translations for the same URLs that you could host on en.domain.com, fr.domain.com, etc.

I suspect many people though (including myself) want the domain.com/foo, domain.com/fr/foo, domain.com/zh/foo approach, so that would still require additional work in another PR(s) so that all languages are processed through a single build process.