Explicitly set default locale.

Before adding any I18n, the default locale was irrelevant as all text
was in English.  With alternative translations being added, setting
it explicitly here should ensure English is still displayed unless
the locale is actively changed elsewhere.

N.B. It might be that the default locale itself defaults to English;
I couldn't tell.
Add globalize3
Use a translations table for world locations

This does everything required to move the name and description of
every WorldLocation into a translations table, into which alternative
translations can be added.  The work to actually add alternative
translations or allow them to be displayed will be added in future
commits.

In general this was straightforward; the main issue was how to sort
locations on values no longer in the main table.  As there the number
of locations is limited, I have resorted to sorting them in ruby but
for other model types, a more efficient solution will need to be
found.
Limit the available locales to English, French and Spanish (for now)

I plan on using the available locales to build a select box when
creating a new translation.
Allow admins to add translations of world locations.

This marks significant progress to complete translation of world
locations, though it has some notable shortcomings right now.  Namely:

- It's not yet possible to list or edit existing translations
- There's no mechanism to view translations, without hacking the url

The first of these will be fixed shortly.  The second is deliberate,
as we don't want to expose the ability to switch locales to end users
until much more of the I18n work is complete.  Currently you can
add a translation and then view it by adding a locale parameter, i.e.
/government/world/spain?locale=es but this is likely to just be a
temporary mechanism.
Allow existing world location translations to be edited

In adding this functionality a couple of changes to the original
translation work were required.  Specifically, I found it difficult
ensuring the location was scoped to the correct locale when getting
and setting attributes.  To get around this, I've introduced a
LocaleWrapper object that binds a model to a given locale, and so
far I'm happy with this approach.

There are still some rough edges in the overall functionality which
I will iron out in the next few commits, specifically:

a) Unable to see the english version alongside the new translation
b) Locations are sorted in memory, not sql on index pages
c) LocaleWrapper needs tidying and extracting
Convert tests to new view_test style