A bunch of changes to make DualStorage more flexible/robust

[elad]

Submitted primarily for review and discussion - keeping the diff very short. Note that this is implemented in terms of Store to maintain abstraction of the storage layer.

• Make standalone models (no collection) work with DualStorage. (Issue #98)
• Model-only API:
  • New model-only API: isDirtyOrDestroyed, returns 'dirty', 'destroyed', or false. (Discussed in comments to issue #98)
• Collection-only API:
  • hasDirtyOrDestroyed, returns true or false. (Discussed in comments to issue #105)
• Model and Collection API:
  • discard(what), discards dirty models if what is 'dirty', destroyed models if it's destroyed, or both if it's falsey. When used on a standalone model, data will be discarded only if the model is dirty, destroyed, or either, respectively. (Discussed in comments to issue #105)
• Allow specifying remote or true booleans on individual Backbone.sync requests. (Discussed in comments to issue #105)

[nilbus]

I didn't mean to suggest that we add any new methods on the collection. Instead I was just thinking that it might be nice if the existing methods didn't reference localStorage, etc. and instead asked Store.

Adding methods to the model prototype is helpful though.

There are a few good improvements in here. I am in the middle of rewriting our test suite and merging the async branch for supporting other backends, so I will come back to this after that's done.

[elad]

First, thanks for working on the Mocha testsuite and abstracting the storage layer - those are really important changes!

Just to clarify though: do you mean we should not add any new methods on the collection at all? if so, how would developers access new features like discard?

[nilbus]

Sorry for miscommunicating. I am not against adding new methods as they are needed. I was under the impression that you added some of those because I had suggested adding them, which I hadn't. I am okay with adding new methods that are useful and not redundant.

[elad]

Oh, no, I meant that you suggested that functionality should be implemented in terms of Store rather than localStorage to keep the abstraction, that's all.