Translate people profiles

Pivotal story: [Translation of people profiles in world locations](https://www.pivotaltracker.com/story/show/43564073)

These changes allow an admin user to add translations for a person's biography and for a role's name and responsibilities. If a person has a translation for their biography and corresponding translations for at least the names of *all* their *current* roles, then a translated version of the public-facing person page is made available.

These changes also allow translations to be edited and deleted. Translation form input fields in right-to-left languages should be given the appropriate direction. Person pages with right-to-left language translations should be displayed correctly.

The admin UI for people and roles was already a bit clunky and I think these changes will make that more obvious. I think it would make more sense if it were possible to edit a person and their current roles in one go. However, since that would be quite a bit more work and somewhat orthogonal to this story, I haven't made any changes in that direction.

The public-facing person page also shows the names of the roles the person *previously* had. These can be translated, but whether they do have a translation or not does not affect whether the translated person page is available.

Only worldwide roles can have translations. I decided this would make the admin UI a little less confusing for admin users who don't care about worldwide stuff, but I can see that it might be overly restrictive if e.g. a person has two current roles, one worldwide and one non-worldwide. Or in the case where a person's previous role was non-worldwide.

There is a moderate amount of duplication in across the various model translations controllers that now exist. It would be good to remove this duplication somehow, but I'm keen to get this first cut of the functionality into the hands of Ross et al.

I've introduced `ModelStubbingHelpers#stub_translatable_record` to cope with stubbing of Globalize3 functionality and avoid hitting the database in tests that were using `#stub_record`. The combination of these stub records and Globalize3 has been a real pain, because Globalize3 triggers database queries when reading a translated attribute (it monkey-patches `ActiveRecord::Base#read_attribute`). This is particularly invidious, because `ActiveRecord::Base#inspect` uses `#read_attribute` so it can display attribute values however, with Globalize3, access to a translated attribute value requires a database query. This is compounded by Draper calling `ActiveRecord:Base#inspect` in its constructor and Mocha trying to use `ActiveRecord:Base#inspect` to display errors. The latter can result in a stack overflow error, where calling `#inspect` causes a database query, which causes a Mocha unexpected invocation error, which in turn causes another call to `#inspect`. It may be worth considering stubbing `#inspect` on these stub records to avoid these problems.

Note that I have run all the tests locally against Ruby 1.9.2-p290 and they all pass even without the change to use `FactoryGirl.build_stubbed` which has now been reverted in master. Obviously this is no guarantee that there will not still be segmentation faults on CI, but I'd be pretty hopeful that there will not be.