Search refactor with translatable, admin configurable, complex search filters.

This includes a few side features:

- adoption of django-rest-framework to be able to use the search view as an API. Just append `.json` to the URL or send the appropriate `Accept` header. (Note: this still needs some vetting with regard to throtteling and authentication, both of which are supported out of the box by django-rest-framework. The first may just need a simply bridge to django-valet-keys). The adoption of django-rest-framework will allow us to think about the search much like an API, instead of a monolithic function based view and has very easy hooks for extensions.

- I had to fix the fixtures (hah!) quite a bit to make the tests work. I think some where copy/paste victims and just need some number changes. That said, the tag items particular for wiki documents were wrong since we use a custom tag class instead of taggit's own Tag/TaggedItem class. The `calculate_related_documents` function was broken in that regard, too. I've fixed it but I think we should aim at replacing that feature with "More like this" feature of Elasticsearch. The list of related documents seem to be hidden in the frontend anyway.

- The search filters can be edited in the admin, but I added an initial set of filter as a data migration. The filter groups aren't used in the frontend at all since there isn't a design for that kind of separation yet.

-  Some features that were previously done in the template (e.g. document URL building) are now done in Python to ease implementation. These URLs could potentially be added to the search index, too.

- The search view currently supports setting the number of items per page as a GET variable called `per_page`. Let me know if you want me to disable this again.

- There is a waffle flag called `search_drilldown_faceting` which when it exists toggles two different types of facetting.
  1) one where the results are drilled down like on Amazon product search pages 2) the results of all selected filters are added together (I like 2)

- I disabled the Elasticsearch field analyzer for the tags to prevent not being able to filter by tags that have common words like "a", "the", "this" etc or are flexed forms of verbs like "tagged". This requires reindexing the search index with the `reindex` management command.

- We should speed up the highlighting somehow, bleach is crazy slow in my tests.

- I've added django-dbgettext as an experimental approach for translating database content. The basic (stupidly easy) idea is that it provides a management command that exports database content into Python files that are then scanned by tower/gettext (during deployment?) to generate the POT files, to be translated by the localization platform for UI elements (localize.mozilla.org?). This is the part I want some feedback before merging and it could easily be removed again. The alternative would be to make the Filter model a translatable model with all its downsides, like having to give localizers access to our Django admin to be able to translate filter names.