Adds user-adjustable sorting to aggregated views

Adding this feature required reworking how some aspects of how the
QueryBuilderField worked. Instead of using QueryBuilderField to select views for
the ViewAggregatingResultsRetriever, we now use a GridField (similar to how
HandPickedResultsRetriever works) to select and sort views. Internally this user
an extra SortOrder column on the intersection table.

This change alloed QueryBuilderField to be simplified quite a bit since it no
longer had to support many_many relationships.
Improves appearance of QueryBuilderField

Adds normal CMS admin classes and uses chosen library for autocomplete
selectors
Adds missing public / private declarations
Fixes code formatting
Fixes reference to non-existing CSS file
Fix Sorting of Aggregated Views

Sorting of aggregated views was completely non-functional. This is because
ArrayList::sort() returns a mutated copy of itself, but our code was assuming
that the original list was mutated. This lead to ViewResultsSorters effectively
being a no-op.
Deletes ViewResultsSorters when ViewAggregatingResultsRetriever is deleted

This wasn't breaking anything, but orphaned ViewResultsSorters were being left
around in the DB after the ViewResultsRetriever that referenced them was
deleted. This prevents that from occurring.
Fixes pagination of results from a ViewAggregatingResultsRetriever

ViewAggregatingResultsRetriever was calling View::Results() on each of it's
views to build a coalesced result list. This was flawed, though, because
View::Results contains pagination logic wrapping around the call for
ViewResultsRetriever::results(). By making ViewAggregatingResultsRetriever
call ViewResultsRetriever::results() directly, we bypass this, making pagination
of the final result amalgam work as expected.
Merge branch 'feature_allow_aggregated_view_sorting' into 3.1