Add a converter for transforming multi-language documents

This takes a document with language based keys and transforms it into a
flattened document based on the given language preference and optional
default language.
More generic way to determine if a field is multilingual

By using the language-tags package we can determine if the given
language code is valid. This should cover all languages that are valid
in BCP-47.
Add i18n middleware
Add toJSON filter to translate documents

This checks the options that have been set on the schema in the i18n
middleware and tries to translate the document to that language.
Add tests for translations in the API

This sets the Accept-Language header then checks that the returned
document is in the requested language.
Use Mixed schema type for all keys that aren't arrays

This allows documents to have objects where they are expecting a string
in the schema.
Add http-accept module
Update schemas to allow object keys for translations

The validation was failing when trying to POST a translated key because
it was expecting a string or null value. This overrides all of the
popolo schemas to allow keys to be translatable objects.
Use the Accept-Language header to determine language

For translated keys, loop through the accepted languages and stop after
the first match. Since the 'req.accept.languages' array is in order of
preference this means the first match is the user's preference, then we
fall back to the default if there isn't a match.
Make sure records can be created through the API

Multi-language records should be able to be created via the API without
any validation errors. Only a minor change was needed to double check
the name is a string before indexing it using double-metaphone.
Allow the default language to be configured

Allow the user to specify a default language to fall back to when none
of the requested ones match. This can be configured when popit-api is
run standalone, but can also be used when the app is embedded in popit,
which will allow the user to select a default language for their
instance.
Store translated objects in elasticsearch

Convert all popolo string fields at the top level of the doc into
translated objects so they are stored consistently in elasticsearch.

This only handles popolo fields, if a user is creating custom keys then
it is assumed that they will store those consistently so we don't touch
those.
Drop elasticsearch index before i18n search tests

This should prevent errors like

Error: MapperParsingException[failed to parse [name]]; nested:
ElasticSearchIllegalArgumentException[unknown property [en]];

I've also added a 5s timeout to the whole describe block to hopefully
stop random failures.
Recursively translate nested objects

If the object doesn't look like a translation object then instead of
just returning it as a plain object we recursively call the i18n
function on it to try and translate it.
Recursively translate nested custom arrays

This allows custom nested arrays to be translated correctly by calling
the i18n function recursively.

I've had to swap the order that the json transform filters get run to
avoid a 'Maximum call stack size exceeded' error.
Refactor i18n middleware to use eachSchema function
Merge pull request #45 from mysociety/i18n

I18n
Don't try to translate id keys

This was causing a weird issue where ObjectIds were being 'translated'
to an object with a '_bsontype' key and an internal representation of an
ObjectId.
Upgrade to latest version of mocha

This fixes an error that suddenly started appearing on travis builds
today:

    Error: global leak detected: documents

I'm not sure why upgrading fixes it, but all of the tests still
pass so it doesn't seem to have any negative consequences.
Store each translation as a separate key in elasticsearch

The previous solution of always storing objects in elasticsearch didn't
preserve backwards compatibility. So queries like 'name:Chris' no longer
worked, instead you had to do a query like 'name.en:Chris'. Since there
are already several consumers of the search API it makes sense to try
and maintain the simple version of the query.

Rather than storing language objects in elasticsearch we simply flatten out
any language objects so they take the form {field_name}_{language_code},
e.g.  name_en or name_en-gb. Then the default language for the instance
is stored in the 'name' key so that's still searchable.