Rewrite search controller. Introduce proper HTTP API. Show error message...

...s. Fix bug 956164 and 956919.

The search controller is no longer a spaghettified mess of reads and writes to a gigantic hash.

test_strings now passes. We're down to 1 failing test.

* We now have a publishable, reasonable REST API for searching, triggered by an Accept header of application/json. No more format= querystring param. Bad queries return a 400 so you can detect that easily.
* Show error messages for regexes that are malformed or unable to be accelerated.
* In the query machinery, tolerate queries that don't end up filtering anything. (ES would complain before.) Rather than showing "no results" for the query "df df df" (with all unsearchable bigrams), we show everything. Both alternatives are equally misleading and horrible and will be addressed in the Query Language Refresh.
* Fix bugs on error page wherein (1) part of the content would be hidden behind the search panel and (2) you couldn't do searches from them. (All the attrs of the div tag are necessary.)

The easiest way to review the new search controller is by just reading it. The diff of it is not useful.
Seems like this gets passed as-is into Elasticsearch. Is it possible for this to hose things? Does it require more validation?