Fix mistaken synchronous code in tests
Add has-many support for BasicAdapter
Pass has-many data to basic adapter hooks
Basic saving
Do not allow setting to essentially read-only setters

If you set to any of the essentially read-only computed properties
such as: isLoaded, isReloading etc... on model, you are going to have
a really bad time.
Merge pull request #801 from stefanpenner/unsetableProperties

Do not allow setting to essentially read-only setters
Fix docs for Adapter's map API
Merge pull request #808 from JasonKriss/map-docs

Fix docs for Adapter's map API
Add on-demand hasMany relationships.

With this commit, hasMany relationships can be resolved on-demand without
the need for ids upfront. For example:

	App.Person = DS.Model.extend({
		firstName: DS.attr('string'),
		lastName: DS.attr('string'),
		posts: DS.hasMany(App.Post)
	});

	App.Post = DS.Model.extend({
		person: DS.belongsTo(App.Person),
		message: DS.attr('string')
	});

	var person = store.find(App.Person, 1);

When find is called for a Person with an id of 1 the server can return a
data hash similar to the following:

	{
		person: {
			id: 1,
			firstName: 'John',
			lastname: 'Doe'
		}
	}

Notice that the 'posts' hasMany relationship is left 'undefined' in the hash
returned from the server. The 'undefined' relationship can then be resolved
on-demand at a later time:

	var posts  = person.get('posts');

The adapter's findHasMany method will be provided the parent record (person)
and the hasMany relationship key (posts). The server can be queried with
the parent record type (Person), parent record id (1) and the relationship
key (posts). With that information the server should be able to resolve the
relationship and return the related child records:

	{
		posts: [
			{
				id: 1,
				user_id: 1,
				message: 'Some message...'
			},
			{
				id: 2,
				user_id: 1,
				message: 'Another message...'
			}
		]
	}

You will probably not want to dirty the parent record on a hasMany change
or a belongsTo change if the record being set is the same as the previous:

	App.Adapter = DS.Adapter.extend({
		dirtyRecordsForHasManyChange: Ember.K
		dirtyRecordsForBelongsToChange: function(dirtySet, child, relationship) {
			if (relationship.parentReference !== relationship.secondRecordReference) {
				this._super(dirtySet, child, relationship);
			}
		},
	});

And can 're-use' any previously resolved relationships by doing something like:

	App.Serializer = DS.RESTSerializer.extend({
		materializeHasMany: function(name, record, hash, relationship) {
			var key = this._keyForHasMany(record.constructor, relationship.key),
			    data = record.cacheFor('data'),
			    cache = data && data.hasMany[name],
			    value = this.extractHasMany(record.constructor, hash, key);
			record.materializeHasMany(name, value || cache);
		}
	});

	App.Adapter.reopen({
		serializer: App.Serializer
	});