Fix failing test for model update with custom id attribute.

This commit fixes a failing test for model updates with a custom id
attribute. It changes the strategy how updated fields from server-side
are merged with locally synced models. Instead of merging objects with
`_.extend()`, the received response is merged through `set()` method.

Background
----------
As far as I can judge (I'm very new to the codebase), this issue might
have been introduced with [PR36][1], which introduced merging model after
update. Changing the type of the second argument to `localsync` from
_bb.Model_ to _object_ seemed to cause the unwanted side effect that the
custom id attribute is no longer discoverable from within `localsync`.

Hence, the fixing strategy has been developed around the idea to adhere
to `localsync` type signature. The easiest solution seems to just
overwrite the existing local model instance with the received response
from server through `model.set()`, after previously having parsed the
response through `model.parse()` (just to be compatible to the overall
idea of being agnostic from response formats).

Motivation
----------
I developed this fix in order to get the test suite to all green back
again. I stumbled over the failing test after I checked out the code for
investigation (in pursuit of a completely unrelated thing).

Notes
-----
This is my first contribution to the codebase. Please review my change
thoroughly. I ran the test suite against Chromium and Firefox browsers.
Thanks for your efforts on backbone.dualStorage!

[1]: https://github.com/nilbus/Backbone.dualStorage/pull/36
Force localsync callers to pass real Backbone models.

As a follow-up on issue / pr #51, this change forces localsync to be
called with backbone model or collection objects only.

First, a guard to `localsync` was added, similar as proposed by nilbus
[here](https://github.com/nilbus/Backbone.dualStorage/pull/51#issuecomment-25201923).
The model type restriction is not enfored for the localsync specific
extra methods (clear, hasDirtyOrDestroyed), since they don't use the
parameter at all. The guard was developed test-first to ensure correct
behavior.

Further on, all calls to localsync from dualstorage have been revisited.
The 'read', 'create' and 'update' methods now update the model through
its `set` method before the model is passed on to localsync (instead of
the received object). The changes have been verified through tests.
Consistent merging of local models with remote response.

The `model.set` operations on models prior passing them to localsync
have been refactored to a new helper function

    mergeModelWithRemoteResponse

which updates the model with the remote object properties and returns it
back to the caller.

To ensure that during update no 'change' events are triggered by
backbone, the `silent:true` option is passed along the set call.

All refactorings were accompanied with tests.
Keep the most imporant responsibilities first in the localsync spec

Also make the object literal syntax consistent with the rest of the project.
When testing the model parameter, limit the scope of the specs

Check for a thrown error or not; the code under test does not affect or change the return value.
Stub Store.create to avoid exercising code in Store.
Move assertions about the arguments to localsync into specs that call localsync

This way it's in context, and we need less setup.

Remove spyOnLocalsyncNonDirty, as it seems it's no longer needed.
This note claims spy.mostRecentCall wasn't working:

  Note: Need to go this hacky way because jasmine's spy.mostRecentCall
  was not reporting the last called args properly.

Since there are no calls to mostRecentCall and everything works without
it, using _(calls).every(->), I'm remiving spyOnLocalsyncNonDirty.
De-duplicate checkMergedAttributesOn mock tests

The test "merges updates from the server response into the model attributes on server-persisted models"
is already covered by the specs on checkMergedAttributesOn.
Rename mergeModelWithResponse to updateModelWithResponse

Merge a with b would typically imply merging a into b. In this case, response is merged into the model.
Update localsync with server responses on save/update

Fixes #55

Don't update update the persisted model's attributes; doing this stops
events from being emitted. Instead, create a clone to pass to localsync.
Using this clone allows localsync to know the model class's idAttribute
and store the update attributes from the server, without interfering
with the model being saved.

dualsync read should not merge attributes in this manner though.
When fetch is called, we want to pull the data from the server and pass
it as-is as the response to both localstorage and dualstorage.

The case we're trying to cover here, merging in dualsync, is updating
localsync on model save (create/update) when the server response is not
exactly what we sent in the save request.  The server response will get
processed by Backbone.Model.save and the model attributes will get
updated with the server response. Our localsync store gets left out of
the loop though, which is why we do this.

Test that dualsync fetch/read on a collection calls localsync on each
model in the collection in the response.

Don't test updateModelWithResponse/modelUpdatedWithResponse, because of
its role as a private method for dualsync rather than an external
collaborator. Instead, test for its effect on the public methods.

Rename serverReturnedAttributes to serverResponse, since the server can
return responses other than just one set of attributes.

When (read) fetching a collection, use a better local variable name
(collection) rather than model, which can be confusing.