Improved solution for read-only gapi object properties

This will hopefully resolve, or at least bring us closer to the resolution of #27

While looking into #21, I had to dig a bit deeper into ember-data and found two potential fixes/improvements to the hack we implemented for for #18 with pull request #19.

# Improvement 1

It turns out there's a `normalizePayload` method inside the JSON serializer (which we are using in a slightly modified form). The method looks like this:
```
normalizePayload: function(payload) {
  return payload;
}
```

Basically, this is THE centralized spot where we can deal with the object we got back from gapi having read-only properties.

For now, I've moved the hack there, but I'm still having difficulties finding a proper solution for it.

# Improvement/fix 2

Digging through the real-time api documentation, the only properties that are listed as read-only are `CollaborativeObject` (string, list, map, etc.) ids, so my initial assumption was that these are what's causing the issue. This was **not the case**.

Using https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/getOwnPropertyDescriptor, I found that that the only thing that isn't writable are members of array properties of objects we're getting from gapi.

To elaborate, if this is our slide object:
```
id: "2eyigekaxz"
linkableSlides: Array[1]
position: -1
title: "hhh"
url: "assets/images/background.gif"
version: "xxxxxxxxxx"
widgets: Array[6]
```

`id, linkableSlides, position, title, url, version` and `widgets` ,are all both writable and configurable. However, `linkableSlides[anyIndex]` and `widgets[anyIndex]` are neither writable nor configurable, so it definitely has something to do with arrays specifically.

The **second fix/improvement avoids the `JSON.stringify` hack.**

In `lib/reference.js`, in the `MapReference.serialize` method, we simply check if the property is an array and remap it into a new array if it is, getting rid of the read-only status.

This is still a bit of a hack, but I'm hoping we will be able to ditch if once we figure out the whole `CollaborativeList` thing in #21.

Only one of the two fixes is required for `ember-gdrive` to work, but for now, both are committed so you can decide which one to go with.My vote is for fix 2, since it's an actual, direct fix (as ugly as it may look), when fix 1 is just a generic hack in comparison.

This is fix approach number 1. The clone method's functionality has been moved from the adapter into the `normalizePayload` hook of the `serializer`. It's better placed and easier to manage than what we had, but it's still a generic hack, so my vote is for approach number 2, in the comment above.