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.
When doing API stuff for fjord and richard, I tossed around just using the accept header but then decided to go with a format querystring parameter because it was easier to test in a browser and required shorter curl command lines.

It's kind of a goofy use case, I suppose.

Out of curiosity, do you have a good way to test this in a browser or do you not bother with that use case?