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.