Failing features for non-English news articles

Some overlap between these at the moment whilst I spike-out what the
solution for this will look like
Spike-out some code to allow non-English editions

Because we can no longer assume that an edition is available in
English, we have to work a bit harder to make sure we load editions
in a locale for which we have content for. Here, I've introduced the
concept of a primary locale on Edition. This will be :en if an
English translation is available, or the first available translation
otherwise. The primary locale is used to set up a LocalisedModel of
edition and to make sure we link to the correct version of the
edition.

Notice too that available_in_multiple_languages? has been overriden
for WorldLocationNewsArticle. This is because the original definition
in TranslatableModel makes the assumption that an English version
will always be present.
More spiking for non-English translations

This is an attempt to get around the issue with non-English editions
being invalid when loaded with the global locale set to English.

For example, if the scheduled edition code attempts to load and
publish a non-English edition, it will fail because the edition does
not have the required attributes (title, body, summary) for the
current locale. What I'm trying to do here is to adjust the
validations such that Editions will still be valid without an English
translation. The basic idea is that we should only need to verify
that the translations have all the required fields. i.e. We want to
validate:

  a) that at least one translation exists
  b) that all the translations have the required fields

Sounds simple enough, but because of the way globalize3 hooks into the
model life-cycle, that's not quite so straightforward...

The story begins with the way globalize3 magically manages
translations. Any model that is "translatable" will have a
`translations` association injected into it and any attributes that
have been marked as translatable will have magic getters and setters
defined for them. When these attributes are set, behind the scenes,
globalize3 is caching the values for handling later. When the model
instance is saved, validations fire and non-translatable attributes
are saved to the main model table as normal. The translations are
then saved in `after_create`/`after_update` callbacks (called
`save_translations!`) that globalize3 defines, which cycles through
the cached translation attributes and saves them for the appropriate
locale in the translations table.

Thus because the translations' attributes are not actually set until
after the main object is saved, we cannot validate them from the main
object *before* it is saved.

The code here does two things.

1. It only validates for the presence of title, summary and body on
creation, so when the first (primary locale) version is created, it
correctly validates the required fields using the getters globalize3
defines.

2. It adds a `validates_associated` call to validate the associated
translations, and validations on the translations for title, body
and summary. In theory, this should cover both a) and b) above:

  When an edition is first created, it will not have any translations
  and the fake atttributes are used to validate it.

  When an existing edition is loaded, the validations will fire on its
  translations, and not the magic attributes (which will be blank for
  non-English editions)

This code relies on the master version of globalize3, primarily for
this commit:

  https://github.com/svenfuchs/globalize3/commit/941572c523fcd00905a033ca3486d87f8169b3d6

Without it, `update_attributes` calls are broken†.

There are a bunch of failing tests that need investigating - one unit
test relating to importing invalid translations and a bunch of
functional tests related to scheduled publishing

† I haven't tracked down exactly where it happens, but it would
appear that when `update_attributes` is called with a new locale, an
attempt to save an empty translation instance for that locale is made
*before* the `save_translations!` callback fires, which then updates
the translation with the attributes provided. The problem was occuring
because the save fails, thus the `translations` association includes
an unsaved instance of a translation, which does not get found by the
`find_or_initialize_by_locale` and then when
`record.translations.each(&:reload)` is called, it complains about
not being able to find the translation without an id.