Allow admin users to create & edit translated person biographies.

This includes the ability to edit right-to-left translations in the
admin UI.

There is quite a bit of duplication between the
`PersonTranslationsController` and other similar controllers, but I will
hope to address this in a later commit.

Despite the fix in 13237e4ea7e54c4d3bc9bd8d244fe08ff0655b2f, there's
still some awkwardness in the setup of `PersonPresenterTest`. This seems
to be because the FactoryGirl stub is still affected by Globalize3 and
therefore attempts are made to query the `person_translations` table
unless the `#translations` method is stubbed.
Introduce `ModelStubbingHelpers#stub_translatable_record`.

I was running into problems like the ones described in [1]. This new
helper method adds a stubbed `#translations` method to avoid database
queries that would trigger the `never` expectation setup by
`disable_database_queries` in `test_helper.rb`.

[1] 13237e4ea7e54c4d3bc9bd8d244fe08ff0655b2f
Make translated person biographies available on public website.

Translations for right-to-left languages appear to be displayed
correctly i.e. they use the right-to-left styles. This came "for free"
because of previous work by @tomafro & @edds.

I have followed the pattern used elsewhere of having a couple of
end-to-end Cucumber tests which cover both adding a translation *and*
viewing it on the public website.

The tables I have used in a couple of steps are somewhat overkill, but
the follow the pattern established elsewhere and mean that it would be
easier to add other translated attributes in the future.

I've also added an assertion to a functional test to force me to
introduce the link from the admin UI to the translated person page on
the public website.
Allow admins to remove a translation of a person's biography.

I decided to add a biography to the `@person` created in
`Admin::PersonTranslationsControllerTest#setup`, because without this
(non-required, translated) attribute, no english "translation" is
created.
Display flash notices for person translation operations.
Make role name & responsibilities translatable.

This adds a "Manage translations" link for each role in the admin UI
allowing the name & responsibilities a role to be translated into
multiple languages. This means it's a relatively big commit, but I'm
comfortable with this because most of the functionality is very similar
to other model translations. I'll explain some of the differences below.

The translated name & responsibilities will show up on the
locale-specific version of the public-facing person page, as long
as both the person and *all* their current roles have translations into
a given locale.

I've introduced a couple of methods into the `PersonPresenter` which
cope with the logic described above, but it feels as if it might make
sense to introduce some kind of aggregate class which copes with the
combination of multiple translatable models appearing on a single page.

Given that we also display names of previous roles, we might also
want to take these into account when deciding whether we can display
a person page for a given locale, but I haven't tackled this here.

The admin UI for roles and people was already pretty clunky and I think
these changes may make that more obvious, but that feels like a bigger
issue which I have not tackled here.

As elsewhere I have introduced an *end-to-end* Cucumber scenario which
adds a translation to an existing role and checks that the translated
content is available on the public-facing person page. I have only added
a test for adding a new translation and not editing an existing one,
because I feel that that functionality is covered by the functional
tests.

It's worth noting that I had to use the `as: :role` option in the form
helper in `views/admin/role_translations/edit.html.erb`, because the
role is always an instance of a subclass of `Role`. Without the option
the input fields would be namespaced according to the subclass which
would mess up the parsing of params in `RoleTranslationsController`.

One small thing I had to change was in `Admin::RolesController#destroy`
where it turns out that the translations associated with a role are
destroyed when the role itself is destroyed, which in turn means that
the translated attributes are no longer available.

I've changed all the places that were using
`ModelStubbingHelpers#stub_record` to build a role, to use
`#stub_translatable_record` instead in order to avoid the tests hitting
the database and failing the expectation set by
`#disable_database_queries`.
Only allow translations for worldwide roles.

This means that the "Manage translations" link only shows up against
worldwide roles in the admin UI. I feel that this is likely to make
things less confusing for admins who are not interested in worldwide
roles.

However, if we end up deciding that we want to show translated versions
of previous roles on the public-facing person page, I can see that we
might want to relax this i.e. if an ambassador was formerly in a
non-worldwide role.
Fix logic in TranslatableModel#available_in_multiple_languages?

I've added unit tests for this module. The third one demonstrates the
flaw in the logic:

If a model has translated attributes, but none of those translated
attributes are *required* attributes, then no Globalize3 translations
will be created and `#translated_locales` will return `[]`.

This is probably a slightly unusual situation, but it is possible e.g. a
person is created with *no* English biography. A Spanish biography is
then added to this person, but
`TranslatableModel#available_in_multiple_languages?` would return false
and it would not be possible to view the Spanish version of the person
page.
Fix stub_record tests that seem to only fail in Ruby 1.9.2.

I may have imagined that the tests passed in Ruby 1.9.3, but I'm pretty
certain they did.

The tests failed because of various database queries being triggered in
this test which does not allow database access.
Fix migration so that it runs in the presence of translations

Without this change, running this migration against the most recent code
results in the following error:

    Mysql2::Error: Table 'whitehall_development.person_translations' doesn't
exist
Make it easier to add further localised routing tests

I wanted to add the `localised: true` option to the top level `people` route
but wasn't sure where to test it. I removed all the `localised: true` options
and these were pretty much the only tests that failed, so I figured that I'd
make it easier to add tests for further localised routing changes.
Enable i18n fallbacks in development

This was triggered by me seeing warnings for missing translations when
browsing the site locally. Unless I'm actively working to find missing
translations I think I'd prefer the behaviour to be closer to that of
production, which is why I'm enabling fallbacks in development.
Add localised routing to people

This ensures that /people/<person-slug>.<locale> works correctly. Previously,
you would've had to add the '?locale=<locale>' querystring to view a person in
a different locale. This also ensures that links to people take you to the
page in the locale you're viewing the current page in.

*NOTE* I've had to extend the `stub_translatable_record` helper so that the
`#translations` method responds with something that can answer to `#where`,
which in turn responds with something that can answer to `#exists?`. This is
because methods (specifically, `#available_in_locale?`) now comes into play
when generating the route for a person.
Exclude 'biography' from `Person.columns`

As in d1fc876aae4e7a8dbb8ca74e4b80452102e1e4e4, this will enable us to
gracefully remove the biography column in a future commit (the biography now
comes from the person_translations table).
Exclude 'name' and 'responsibilities' from Role.columns

As in d1fc876aae4e7a8dbb8ca74e4b80452102e1e4e4, this will enable us to
gracefully remove the name and responsibilities columns in a future commit
(these values now comes from the role_translations table).
Move the test for #missing_translations

This tests behaviour provided by TranslatableModel so I'm moving to test
accordingly.
Introduce `TranslatableModel#non_english_translated_locales`

This should allow me to use this, and the related `#missing_translations`
methods in the person, role, world location and worldwide organisation
controllers, thereby DRYing up the index actions.
DRY up person_translations_controller

We can use the methods provided by TranslatableModel to DRY up this
controller.

*NOTE* I've had to explicitly load the person in a before_filter. We were
previously populating the `@person` instance variable with our call to
`#person` in the `#index` action.
DRY up role_translations_controller

We can use the methods provided by TranslatableModel to DRY up this
controller.

*NOTE* I've had to explicitly load the role in a before_filter. We were
previously populating the `@role` instance variable with our call to `#role`
in the `#index` action.
DRY up world_location_translations_controller

We can use the methods provided by TranslatableModel to DRY up this
controller.

*NOTE* I've had to explicitly load the world location in a before_filter. We
were previously populating the `@world_location` instance variable with our
call to `#world_location` in the `#index` action.