Correct pluralization for EventSearch's backend.
Set DataCollector's primary key as set by Pancakes' services.
Embed associated data in EventSearch.

This has a couple benefits:

1. The search becomes self-contained.  Combined with persistence on the
   server, this means that the search parameters remain the same
   forever.  (Or at least as long as Pancakes' database stays intact.)
2. We can send an entire event search in one POST request.  There's
   other ways to do this in Ember Data, but this is the easiest way to
   do it with the built-in REST adapter.

Of course, this also means that we introduce denormalization, but in
this case I think it's acceptable.
The #=requires in adapter.coffee aren't needed.
A feature to demonstrate search submission.

It's @wip, and therefore doesn't yet work.  Something screwy with the
input selectors.
POST /api/v1/event_searches.

NOTE: This doesn't yet work with the frontend due to invalid primary key
settings.  Still looking into that one.
Ember 1.0.0.rc3 and latest Ember Data.

Living on the edge is a good way to bleed, but without this, the
didCommit events don't seem to trigger.

This also gives us access to DS.BasicAdapter, which might be useful if
DS.RESTAdapter becomes aggrevating.
Love EventType and StudyLocation for what they are.

Ember Data expects the ID to map to "id".  It doesn't have to, though,
which is quite convenient, as neither EventType nor StudyLocation have
an "id" property.  (They are uniquely identifiable, but "id" is not the
appropriate property name in either case.)

Also camelCased EventType's properties to give it more of that DS.Model
feel.
Simplify Pancakes.Adapter.

The FixtureAdapter isn't really needed anymore.
Cosmetics.
Don't return the created EventSearch.

Reasons:

1. Actually, this is a hack.  There's a glitch in current Ember Data
   where embedded entities returned from the server are re-read and
   prepared to be reinserted into a Store, but one of two undesirable
   behaviors happen:

   a. If the embedded entity has an "id" property and an entity with the
      same ID already exists in a Store, an error will be raised.
   b. If the embedded entity has a primary key that is not "id" (but is
      nevertheless declared via the Adapter), the embedded entity will
      be inserted into the target Store.  This will almost always create
      a duplicate record.

2. Despite the hackish nature of (1), returning the created EventSearch
   isn't necessary because the client determines the entire content of
   an EventSearch object.  (Well, almost.  The ID isn't calculated
   client-side, but that isn't that important -- and if I want more
   purity I can just calculate a UUID client-side.)  All the client
   needs is acknowledgment.
Move towards client-side UUID generation for EventSearches.

The main reason is that extracting an ID from a server payload is more
fiddly work than just stating "oh, we have nothing to read back".

This commit is (a lot) more code, but I think it's worth it.  It means
that the client now truly needs _only_ an acknowledgment from the server
to know that its view of the world is in sync with the server's; no ID
munging is required.

This commit also unifies the create and update actions on
EventSearchesController, since they're now the same action.
PUT a search record to the backend.
Fix primary key configuration in the Ember app.

The Ember Data documentation states that e.g.

    Adapter.map('App.Model', {
      primaryKey: 'uuid'
    });

will work.  That form, however, doesn't set App.Model's primary key via
Adapter to uuid; it'll still be id.

Extending the serializer and defining my own primaryKey function is the
only way I found that actually makes this work.  With this change,
visiting an event_searches.show page now no longer shows duplicate event
types, data collectors, or study locations.
ActiveRecord::Base.set_primary_key is deprecated.
A stand-in view for event_searches.show.

To be filled in soon.
The "search results in progress notification" feature is done.
Don't truncate the test database.

Truncation is raising errors like this in scenarios:

    SQLite3::SQLException: no such table: sqlite_sequence: DELETE FROM
    sqlite_sequence where name = 'event_searches';

I would investigate this error, but I don't care.  The cleanliness of
the databae doesn't really matter, beyond guarding against the
(theoretically massively improbable) chance of a UUID collision.  (And
*if* we get collisions, we have bigger problems, like Pancakes'
request/response model being totally wrong.)