Update Sidekiq (and Celluloid, too).

Also explicitly require redis-namespace where I forgot to do that.
A new query runner.

The old reporter-based system had a few problems:

1. It wasn't at all clear what the return value of the queued future
   was.
2. Handling job results required a really awkward set of five procs.
3. Tests? Nope.

This new query runner runs job-like objects.  Jobs consist of code to
run as well as methods that are called when the runner detects success,
failure, timeout, or a rescuable error.

ENGINEERING SIDE NOTE: I'm not sure how wise it is to e.g. invoke a
method on a job whose #call raised an error.  It is certainly safest to
assume that an object that raised an exception is in an unusable state,
and from that perspective what I'm doing is blatantly stupid.

On the other hand, all of my job updates are ultimately going to the
client via Redis, and if the job or Pancakes' environment is in such a
bad state that I can't even write to Redis, then I've got bigger
problems.  So whatever.  If this becomes a problem, then we'll find a
way to deal with it.
EventReport execution, collation, and data retrieval.

Also wire up EventSearch#data, which retrieves the data of the latest
report for that search.  (It's a lot like EventSearch#status.)
Demonstrate that we can show search results.

(We can't do that yet.)
Add some test data to the Cases mock.
After scenarios, log out of CAS *and* the application.

Aker's /logout endpoint does both for us.

Failure to do this results in stale PGT data hanging around in the
application session.
When a model is deserialized, mark it as loaded.

Status-based observes on EventSearchesShowController depend on this.
Show a spinner when working, a grid when we're done.
The "I see search results" scenario should now pass.

What's that, you say?  There aren't really any search results on the
page?  Yes, you're right.   That's because this scenario is crazy
simple.

Commits to be made Real Soon Now will add better checks.
wat