Associations should respect namingConvention
Makes model/record terminology consistent.

Previously, there was some confusion internally
about what was a record and what was a model. This
commit makes the terminology consistent. A model
is a schema definition that creates a subclass of
DS.Model. Instances of those subclasses are called
records. A record corresponds to a single entry
in the persistence layer, as loaded by the
adapter.

To support this change, DS.ModelArray and its
subclasses are now named DS.RecordArray. Since
you should not be using these class names directly
(but rather have them returned by store methods
such as find() and filter()), this should not be
a breaking API change and thus we have not updated
the API revision number.
Add intro documentation to DS.Model states
Added DS.Transaction#rollback()

Transactions now have a rollback() method that
causes all of the records that belong to them to
be reset to their state when they were first added
to the transaction.

The only exception to this is newly created
states, which immediately become deleted upon
transaction rollback.
Refactors and adds documentation to DS.Transaction
Remove new deleted records from record arrays

Fixes #168. Previously, only records that were
sent to the adapter were being removed from
record arrays. This is because the logic for
removing them was in the deleted.start enter
transition event, but new records that are deleted
transition directly to the deleted.saved state
(because deleting a new record is effectively a
no-op; the adapter should never be notified about
the record).

As part of this change, we now have records
that transition from created.uncommitted directly
move themselves to their transaction's clean
bucket (as they do not need to be sent to the
adapter).

This also fixes a bug where updated and
uncommitted records were moving themselves to the
clean bucket. Only newly created records should
do this; updated records should move to the
transaction's deleted bucket when deleted.
Rename model_array_test -> record_array_test
Fixes bug when record is modified then deleted

Because we defer updating record arrays to the
end of the run loop, but we immediately remove
records from record arrays if they are deleted,
there existed a race condition where, if in the
same run loop, a record was modified and then
deleted.

In that case, the record would be removed from the
record array, but at the end of the run loop, it
would be re-evaluated and potentially added back
to filtered record arrays.

This commit updates the test to take the deferred
scheduling into account, and does not bother
updating record arrays with records that have
been deleted.
Merge pull request #199 from rlivsey/has-one-naming-conventions

Associations should respect namingConvention
Add hook to generate client-side IDs

Previously, the store assumed that record IDs
would always be generated on the server, and
did not update bookkeeping information about
server IDs until the `didCreateRecord` method
was called.

Now, adapters may optionally implement the
`generateIdForRecord` method, which is invoked
each time a new record is created. If this method
exists, its return value will be used as the
record's ID, and internal store bookkeeping will
be updated.

This commit also adds some cursory documentation
to the DS.Adapter file.