I18n

This PR implements a basic set up for abstracting content in the views into a central locale file so that translating the site into other languages will be feasible in the future.

There are at least a few considerations to make before merging this:

1. How should we indicate the current locale in the URL? At first, we (@oshiho3, @macckii and me) decided to scope all routes to the locale parameter so that urls would look like this: http://growstuff.org/en. However, that predictably broke a lot of tests. So we ended up opting for a simple query parameter that looks like this: http://growstuff.org/?locale=en. It's a bit cumbersome but it should work for the time being. The locale parameter is totally optional and defaults to **en**, so no one's bookmarks will get jacked up.

2. The organization of the locale files should definitely be considered carefully. I've followed the view directory structure, which seems relatively uncontroversial, but there are some differing schools of thought on this. I'd recommend checking out this [SO thread](http://stackoverflow.com/questions/10282857/how-do-you-structure-i18n-yaml-files-in-rails). Additionally, this thread offers a pretty [convincing refutation](http://stackoverflow.com/questions/11097572/refactoring-ruby-on-rails-i18n-yaml-files-using-dictionaries) of drying up your locale files with a dictionary.

3. Since we're passing in the links that may be contained within each translation key to the translate method, these method calls get a bit long. I couldn't find a way to format the code to make it readable because of Haml's significant white space. Very open to suggestions on that one.

We added a Japanese locale file but only for the purpose of testing changing the locale.


@Skud: I added this conditional so it wouldn't be necessary to pass the locale into an RSpec `have_link` matcher. I just realized though that if we start setting the locale in a subdomain (which I think is a good idea) then this method will be moot anyway.