Added settings for modeltranslation integration.

If USE_MODELTRANSLATION is set to true, modeltranslation is inserted
into optional apps and content translation code becomes active.
The setting is visible in templates and controls modeltranslation
autodiscovery (so content translation may be used without i18n).

Other than that, default Mezzanine configuration is already suitable
for multilingual projects, i18n and languages settings, i18n context
processor, locale middleware and i18n patterns are in place.

This commit also introduces a TestRunner that automatically adds
translation columns to the test database.
The test runner relies on some proposed modeltranslation changes:
https://github.com/deschler/django-modeltranslation/pull/276.

An important tests concern is to check, if introducing the new code
does not cause any side-effects when USE_MODELTRANSLATION is false.
All tests for that should go into the NoContentTranslation test case.

TODO: MODELTRANSLATION_MIGRATIONS_IGNORE is not implemented.
Registered most Mezzanine models for translation.

Excluding Keyword and Settings as they need some special handling,
but including the abstract Displayable as it's instantiated for
sitemap generation.

Base classes need to be registered for translation before their
descendants, so the installed apps order needed to be modifed a bit.

Having a test pointing out unregistered textual fields should make
maintaining the integration easier -- most such new fields should be
made translatable by adding to the appropriate translation.py.
Added processing for fields derived from translated fields.

Fields that need to be generated for all languages are:
* Slugged.slug,
* MetaData.description,
* Displayable.short_url,
* Page.titles.
Moreover, when generating description one needs to be careful not to
use existing translated description.

Factored out two helpers that may be useful for similar tasks in user
code. The disable_fallbacks() context prevents getting value from a
default language when one for the active one is missing, useful when
you need to know if a value in the current language is available.
The for_all_languages() function executes a function with each of the
available languages activated in turn.

The for_all_languages() function and the disable_fallbacks() manager
are used outside of USE_MODELTRANSLATION conditions, so tests with
enabled and disabled content translation are needed for them.
Model.save() should not use any more queries with content translation
than without it, query counts in both save performance tests should be
updated in unison.

TODO: Propose light changes to trans_null upstream.
TODO: Investigate Page.save() queries count on master.
Implemented keywords translation.

Assignments are intended to be the same for every language, thus only
Keyword.title and keywords_string (on concrete subclasses of MetaData)
are made translatable, with the latter recomputed on change for all
languages as with other derived attributes.

Page admin only allows entering keywords in the active language (there
doesn't seem to be any sensible way to inline translations), so
KeywordAdmin (under Content menu) is exposed separately to make it
possible to translate keywords.
Prevented inserting translation fields into forms as extra fields,
TranslationAdmin handles them properly on its own.
Based all admins that may manage models with translated fields on
appropriate modeltranslation admins.

The default is to use modeltranslation scripts to display translation
fields as tabs. You may derive your model admins from TranslationAdmin
(from mezzanine.core) even if you don't use content translation at
the moment.

With modeltranslation the PageAdminForm post will contain multiple
values for slug_<langcode> instead of just a single slug value, thus
we need to repeat the propagation for all available languages.

Fixed a minor error due to out-of-order cherry-picking.
Added a new update_generated_fields command.

The command simply resaves all models basing on anything that may have
translated generated fields (currently Slugged, MetaData and Page).

With some fields, one cannot always rely on translation fallbacks, as
they don't work with filtering / lookups. For example, if you create a
new project loading example fixtures, migrate and update translation
fields, you won't be able to browse most pages in any non-default
language until you give them a chance to generate translated slugs.

The command may also be used to reset all slugs (thus regenerating
them from titles).

TODO: Allow registering bases with generated translated fields.
Allowed testing of modeltranslation (and all other optional apps).

There was probably some reason for excluding these from testing,
however it could be unpleasantly surprising to check that all the
tests pass on a testing environment, but then something fails due
to an optional app being imported in production.
Made modeltranslation fields on lists narrower, so a couple of
translations can fit.

This also gives a cleaner layout with vanilla admin in some places
(e.g. Cartridge Sale inline).

It would be nice to display just one translation for a whole inline
and control which one is displayed with the main language switch / tabs.
However, this would require a specific script for Mezzanine's dynamic,
sortable inlines. There's a sketch of a solution on the branch:
modeltranslation/feature/hide-inactive-untabbed.