Move <script> tags to top of body

Having <script> tags at the bottom of the <body> caused some widgets
that relied upon JavaScript to fail, as the required libraries had not
been loaded at the point where the widgets were added to the page.
Refactor edit handler JavaScript integration

Edit handler panels which required JavaScript provided the JavaScript in
a `render_js` function, the output of which was collected together and
inserted after the `<script>` tags in the footer. Now that the
`<script>` tags are at the top of the `<body>`, these collected
initialisations were failing when they could not find the elements.

A new set of widgets have been created: `AdminPageChooser`,
`AdminImageChooser`, `AdminSnippetChooser`, `AdminDocumentChooser`.
These widgets output the initialisation JavaScript in a `<script>` tag
immediately following the widget itself, assuming that the required
external libraries and scripts are now included further up in the page.
This is how the GeoDjango fields from Django work, as well as many other
third party widgets. It makes writing integrations for arbitary widgets
easy, as they do not have to know anything about Wagtail edit handlers.

This also removes the need for the `fixPrefix()` JavaScript function
wrapping all field initialisers. As the fields are initialised as they
are inserted in to the page, any scripts included with them are inserted
at the same time. Additionally, the `__prefix__` placeholder in empty
form fields is also present in the initialisation scripts, and is fixed
at the same time. A template tag `escapescript` has been added to help
with this, to prevent `<script>` initialisation blocks from prematurely
closing the `<script type='text/django-form-template'>` tags.
Merge branch 'bug/missing-migration' into bug/scripts-at-bottom

* bug/missing-migration:
  Add missing migrations
Fix migrations after merging in missing migrations
Fix Python 2.6 compatibility
Created BaseSearchResults class

Moved some logic from ElasticSearchResults into it
DB search now returns a SearchResults object

Previously, it returned a QuerySet which gave the database backend much
more API than the Elasticsearch backend has. Which could potentially
cause issues if the developer is using the DB backend locally and the
Elasticsearch backend on their production server.

Fixes #460
Created BaseSearchQuery class

Moved some logic from ElasticSearchQuery into it
Added DBSearchQuery class

This makes sure that the user is not filtering on any fields that are
not in search_fields. It also prevents the user from using any features
of QuerySet that are not in the search API
Make default methods raise NotImplementedError
Added failing test for #756
Don't clobber latest_revision_created_at

Fixes #756

This field was being set to None whenever a revision was pushed live
Added failing test for #735
Don't update descendant urls if slug not updated

Fixes #735

Previously, if you called Page.save with update_fields and didn't include
'slug', it would still attempt to update URL paths of descendant pages.

Wagtail 0.7 introduced a feature where it saves the latest revisions
created at date on the Page. This requires a Page.save call which used
update_fields. The bug caused update_descendant_paths to be called
anyway even though the slug wasn't committed to the database.

This caused Issue 735 because publishing a page will both save a
revision and save a page causing two hits to update_descendant_paths.
Running this method twice caused all descendant pages url_path
attributes to get mangled.
Unit test for form-builder forms with multiple checkboxes
Use form.cleaned_data when processing submissions

This fixes #584. It also doesn't pack single values into lists and will
remove csrftoken for us.
release note for #768
Merge branch 'kaedroho-mope-584-fix-formbuilder-checkboxes'
Merge pull request #769 from kaedroho/issue-735

Don't update descendant urls if slug not updated. Fixes #735
Release note + upgrade note for #769