Do not queue event search jobs on PUT.

A user may perform a GET on any event search at any time; however, it is
possible that we will not be able to service the request out of cache,
due to data expiration.  We therefore need an endpoint to explicitly
trigger a refresh.  However, once we've got that, there's not really any
reason left to queue items from two endpoints.

Well, "avoiding round-trips" could be a reason.  I'll have to see how
badly that one extra request per search hurts things.
Richer query status reporting.

In particular, we now have:

1. A specification for the status JSON structure.  Unfortunately, it's
   buried in the model specs, but it's a start.
2. Explicit started and done notifications for all queries in a set.
   (Near-future task: these objects concern query sets, not individual
   queries.  Names ought to be fixed.)
Straighten out content bindings for event_searches.{new, show}.

This was previously really confusing, what with my "bind an
ObjectController's content to another ObjectController's content"
weirdness.

This commit is arguably no less weird, but is at least more explicit
about it.
Shift ID generation to the server.

Two reasons:

1. We are sending server-generated data (i.e. URLs) back.
2. ActionPack's default responder issues a 204 on PUTs and I don't feel
   like changing this.

This change requires a couple of other changes:

1. ActionPack's default responder returns a response body on POST, so we
   now make use of POST again.
2. With this change, we also no longer need to consider the HTTP
   response in full.  The jQuery linkheaders and uritemplate plugins
   have therefore been removed.
Move query-related code to a QuerySet namespace.

I'll probably also rename "tag" to "location" to clarify the purpose of
that tag.  There is currently no reason why Pancakes would run queries
across anything _other_ than study locations, and calling query tags
"locations" makes the backend -> frontend flow of that data much more
obvious.
Explicitly record query set startup.

The previous "presence of at least one query" logic failed to account
for the zero-location case.  (Admittedly it's a degenerate case, but
there's no reason why we shouldn't properly handle it.)
Add Font Awesome for UI icons.

The _icons.css in this commit is an abridged version of the CSS that
ships with Font Awesome.  I might just throw the whole thing in once I'm
confident that it won't affect any other styles.
Squash this into the FA stylesheet intro.
Test for progress indicator presence on search execution.
Update query set status.

Yes, there's a lot more going on here than is necessary to satisfy the
"when a search is started, progress is updated" feature.  Even better,
none of this new code has tests.

The justifications exist, but they're weak, so I won't bother with
them.  Instead, I'll just describe how this code works.

Status updates consist of two parts.  The first part addresses the
status of the query set as a whole; the second part addresses elements
in the query set.  The first part is set on the search object and is the
basis for the values of the isStarted and isDone properties.  The second
part is also set on the search object, but is also sent to a
LocationStatusController, which is used to render a status glyph for
each location.

Other data flows:

1. When we enter the event_searches.show route (either from .new or
   direct entry), we end up with an EventSearch model.  This model
   becomes EventSearchesShowController's content.

2. When the search finishes loading, we request its status.  Once
   we've gotten that, we check whether or not the server has started the
   search job.  If it hasn't, we kick it off.

3. Kicking off a status update also updates an isDone property on the
   search model.  If that property is false, we kick off a poller timer to
   periodically update status.

To do:

In flow #2, "started" isn't quite the right criterion.  We really only
want to kick off a job if (a) a refresh was explicitly requested or (b)
the job hasn't been *queued* yet.  Implementing (b) will require a bit
more server work.
Fix title binding for study location selector.
jQuery's response datatype guessing works well enough.