Add control over ordering of facet values

Returned facet values can be ordered by setting the "order" option in a
facet parameter.  The available orderings are:

 - count: order by the number of documents in the search matching the
   facet value.
 - slug: the slug in the facet value
 - link: the link in the facet value
 - title: the title in the facet value
 - filtered: whether the value is used in an active filter

Each ordering may be preceded by a "-" to sort in descending order.
Multiple orderings can be specified, in priority order, separated by a
colon.  The default ordering is "filtered:-count:slug".

Previously, the hard-coded ordering was equivalent to "filtered:-count",
with items with an equal count being returned in whatever order
elasticsearch returned the values (which is, I believe, dependent on
insertion order of documents in the elasticsearch database).  Some tests
needed updating to reflect the final sort by slug instead of
elasticsearch order.

This also changes the return format of all facets to the "expanded"
form.  ie: instead of returning a string for the value, return a hash,
containing at the minimum a "slug" key.  This was already the return
format for the organisations and specialist_sections facets, which are
the only ones in use, and it's better (and less code) to be consistent.
This change did result in an unfortunately large amount of test churn,
sadly.

Related story: https://www.pivotaltracker.com/story/show/75037392
This function is doing quite a lot of things all mixed together. What about taking a more piecemeal approach like this:

```ruby
def order
  orders = character_separated_param("order", ":").map { |order|
    if order.start_with?('-')
      [order[1..-1], -1]
    else
      [order, 1]
    end
  }

  valid_orders, invalid_orders = orders.partition { |option, _|
    ALLOWED_FACET_SORT_OPTIONS.include?(option)
  }

  invalid_orders.each do |option, _|
    @errors << %{"#{option}" is not a valid sort option#{facet_description}}
  end

  results = valid_orders.map { |option, direction|
    [option.to_sym, direction]
  }

  if results.empty?
    DEFAULT_FACET_SORT
  else
    results
  end
end
```

By breaking the steps down into pieces that do single things and avoiding mutation of shared variables it makes it easier to reason about each piece of behaviour, and makes it a lot more obvious where we could be extracting new methods to simplify further or allow reuse.

I think the `facet_options` method below could benefit from a similar breakdown.