solr_facet_params defaults to sort=index

The Blacklight action for listing individual facet values (eg from a 'more' click on facet)
in the default/common case does not send a facet.sort parameter, so gets the Solr default
of sort by 'count'. 

However, the parts of BL that display the individual facet list assume that if no explicit sort is given, the sort will be 'index' (ie alphabetical, more or less). 

This leads to a mis-match you can see in the demo app, where the values are sorted by 'count',
but in the sort choices at the bottom of the screen, the 'A-Z Sort' choice is mistakenly shown as selected. 

Eg: http://demo.projectblacklight.org/catalog/facet/language_facet

![screenshot 2014-08-21 16 09 42](https://cloud.githubusercontent.com/assets/149304/4002963/07e74fc2-2972-11e4-8796-a9db937038d4.png)


This commit makes 'index' the default sort in fetching again, as the UX expects, and as used to be the case in older versions of BL when the UX was written. 

This is just the simplest thing to make the common case seen in the demo app consistent again. Things that might be nice but we are not doing here:

* There may still be some cases with a mis-match, I don't entirely understand the stuff around `input[  Blacklight::Solr::FacetPaginator.request_keys[:sort] ]`
* ideally this would be configurable, different installations might want different default sorts on the facet drill-down page (or even different for different facets). This doesn't do that either. 

It just restores the common standard case, as displayed in the demo app, to consistency with as simple code as possible, returning BL to how it worked in past versions (not entirely sure when it changed). 
I am not sure that we have guaranteed access to echo'd parameters -- does it depend on if Solr is set up to echo, or does BL ask for echo'd parameters regardless?

But if you don't like this solution, I won't do more work to try and make the tests pass (I still can't get tests to run locally on my machine despite many frustrating hours spent on it). 

But I really do want a bugfix in my app that's demonstrating the bug, along with the BL demo. I don't really have time to work on figuring out or implementing a more complete solution right now. Is there any chance you'd accept this simple solution until someone has the time and inclination to implement a better one?