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.