Records move to default transaction after commit

If a transaction is committed, the records that
belong to it should be moved back to the default
transaction. Additionally, if the default
transaction is committed, those records should be
moved to the *new* default transaction.

Additionally, records should be able to be moved
between transactions if they are still clean.
Records can now be removed from transactions
with the remove() method.
Cacheable attributes
Allowing errors to be undefined

When we bind to an error property in the view, it sets the
value to undefined.  This causes the errors to not be an empty
object, thus the model never transitions out of invalid.

Also deleted our least prefered version of isEmptyObject,
since having two did not seem necessary.
Enable boss mode
Include list of breaking API changes
Track canonical data and changes independently.

* Previously, changes to a record were stored
  directly on the data hash. This meant that after
  a change had been made, it was not possible to
  determine the previous, "server truth" value.
* Now, a record has both a `data` hash and a
  `changes` hash. This lays the groundwork for
  transaction rollbacks, as well as saving the
  foreign key on child records when they are added
  or removed from a hasMany association.
* Now that `data` only holds server truth data and
  not the changes, adapters should use the new
  `getJSON()` method to determine what data should
  be sent to the server.
* Updates the REST adapter to use getJSON()
* This commit also lays the groundwork for the
  ability to do merges if a dirty record is
  reloaded from the server.
Update BREAKING_CHANGES.md
Rename record's `data` to `savedData`

This is so we can reclaim `data` for a data
proxy that understands the `changed` hash (which
we are about to rename `unsavedData`).
Rename `changes` hash to `unsavedData`
Consolidate data modification to DataProxy object
Use DataProxy & toJSON instead of raw data hash

Previously, a record's data was stored in a hash
that was referenced by both the store and the
record. Now that we have split the "canonical"
source of data and the pending changes that have
not yet been committed, we have created an
internal DataProxy object that coalesces these
two hashes into a transparent object that will
return the correct value when asked.

As part of this change, `data` semantically no
longer means "the data hash to be sent to the
server." In this case, you should use the
`toJSON()` method.
Rename setData to didChangeData
Implement breaking changes warning

Ember Data's policy about breaking changes is to
follow semver versioning. However, as ember-data
has not yet reached 1.0, semver allows to make
breaking changes on any release.

To avoid accumulating cruft from features that
didn't make it into 1.0, we will increment a
revision counter every time we introduce a
breaking change, and raise an exception pointing
the library user to BREAKING_CHANGES.md, which
describes the breaking changes and how to update
applications.

See https://github.com/emberjs/data/blob/master/BREAKING_CHANGES.md
for more details on the policy.
Update docs to suggest best practices

Because it is sometimes possible for references
to not be set up yet (especially with tree-like
structures involving `belongsTo`), document the
String form of associations.
Merge branch 'master' of https://github.com/caligo-mentis/data into caligo-mentis-master

Conflicts:
	packages/ember-data/lib/system/model/attributes.js
	packages/ember-data/tests/unit/model_test.js
Merge pull request #117 from vr-pair/allow-undefined-error-values

Allowing errors to be undefined
Fix bug in attributes from previous commit

We should always expect that values set on a
record's attribute round-trip through the
transform process at least once.

For example, if I set the number 1 on a string
attribute, I would expect that the next time
I retrieve that attribute, it is the string "1".

After that, however, subsequent gets should return
objects with the same identity.
Allow adapters to load new data for clean records
Merge pull request #113 from ghempton/jsonless-get

Get request should not json-encode parameters.
Primary keys of 0 are allowed (closes #98)