Fix hasMany association access during initialization

Accessing hasMany associations in a model's initializer was triggering a
second materialization: first when the hasMany access was attempted, then
again when the store finished initializing the new record. The second
materialization erroneously reset all of the model's data.

    App.Post = DS.Model.extend({
      comments: DS.hasMany(App.Comment),

      init: function() {
        this._super.apply(this, arguments);

        var comments = this.get('comments');

        // ...
      }
    })

This error also occurred when setting observers on a hasMany
association, as this would also trigger a hasMany access during
initialization (in order to add the array observer):

    App.Post = DS.Model.extend({
      comments: DS.hasMany(App.Comment),

      commentsDidChange: function() {
        // ...
      }.observes('comments.@each')
    })
Delay saving children until parents are ready

Relational databases store the foreign key on the
child. If the parent of a child is new, that
record must be created first before the child can
be saved, as the child needs to know the parent's
primary key.

The DS.RESTAdapter now observes new parents of
dependent children, delaying their committal until
the parent has been created.
Allow sideloading records while in flight

In some circumstances, a record may need to have its data sideloaded
while it is still in flight.

For example, when creating a parent and child in the same commit, the
child may have updated data for the parent that should be inserted into
the store. In the case of DS.RESTAdapter, the parent will still be in
flight despite having been saved first, as it will be waiting on the
child to declare the relationship change between them clean.
Add hook for preserving dirty children on load

This is specifically needed for the REST adapter to ensure that dirty
children are preserved when new parent data comes back from the server.
Because the children are responsible for saving the relationship, the
parent record on the server won't yet know about the children. If the
children are dirty, it means they will be persisted to the server on
their transaction's next commit, at which point the server will then
know about them.
Add hasOne association

Models can now define a hasOne association as the inverse of a belongsTo
association:

  App.Person = DS.Model.extend({
    heart: DS.hasOne(App.Heart)
  });

  App.Heart = DS.Model.extend({
    person: DS.belongsTo(App.Person)
  });

Includes updates for DS.RESTSerializer to parse hasOne information out
of incoming record data but not include it with outgoing data.
Merge branch 'fix_get_has_many_in_init' into patches
Merge branch 'parent-child-commit-fix' into patches
Merge branch 'has_one' into patches