Include deleted records information in serialized data

The current implementation of serializers, when used in `embedded` form, will not include deleted records. I cannot find official docs on this, but [this comment][gordon-comment] from @ghempton endorses and explains the rationale as:

> deleting an embedded child needs to be handled by your backend implementation. We inspect the params that are sent to the server and delete children that aren't present.

The current implementation is, however, flawed in three aspects:

1. It expects the server to send over a full set of `children` to any `parent` model to `ember`. This is the simple approach, and will indeed suffice for demo `todo` apps. However, a real world production app can conceivably have hundreds thousands of `children`, such that the implementation would likely utilize pagination, and fetch only a subset of records each time. (Even a `phonebook` or a `blog` demo app can reach hundreds of records easily.) A server would thus be unable to infer deleted records from the (incomplete) set of records being sent back in the serialization.

2. It fails when the server database is not synchronized with the `ember` one. Again, a `todo` app would only have one user at a time, so this is not an issue. However, a real world production app would have multiple users, each user can send modifications and delete requests at the same time. Even if the server implements a push system to sync the `ember` databases, there is still no guarantee that the serializations generated by `ember-data` are based off the latest version of the server database. The server, therefore, cannot infer deleted records *reliably* from any serialization sent from a client. (Besides, I consider it bad UI if, let's say, a user is editing a form, and suddenly several rows vanish because a server has pushed some deletions made by another user.)

3. It is expensive. If I merely delete one `child` from, let's say, 500 `children`, the serialization will still need to send information of 499 `children` in order for the server to infer the deleted one. Far heavier but unnecessary load on bandwidth, not to mention far more work for the server.

This PR adds deleted record information to the serializations. Since `ember-data` explicitly declares itself to follow / work with rails' [`active_model_serializers`][ams], I have adopted the rails convention that is expected from a model:

```rb
class Post < ActiveRecord::Base
  has_many :comments
  attr_accessible :title, :comments_attributes
  accepts_nested_attributes_for :comments, allow_destroy: true
end
```

such that the corresponding serialization for a deleted `comment` (inside a `post` serialization) will simply be:

```json
{ "id": 1, "_destroy": true }
```

Now, the server can reliably (and cheaply) determine which records are deleted, by whom (from which request). Collusion logic and treatment can then reliably stem from this information.

[gordon-comment]: https://github.com/emberjs/data/pull/724#issuecomment-13509704
[ams]: https://github.com/rails-api/active_model_serializers