dojo/store/observable/* Proposal

The following changes constitute my proposal for an alternative observable store API [as documented here](https://github.com/Zarillion/dojo/wiki/dojo.store.observable-Stores). This could be used to solve a number of outstanding bugs in the dgrid project, including [this one](https://github.com/SitePen/dgrid/issues/714#issuecomment-25843753) in which this sort of observable implementation was first discussed. Some aspects of the design: 

* Materialized queries eliminate the need for results to be filtered and sorted prior to each page request
* Consistent start/count values for pages; only pages which overlap with the bottom of the query are allowed to be incomplete
* Well defined and heavily tested page-update events
* Shared implementations for materialized queries and pages used by both Memory and JsonRest
* Consistent ordering of changes for remote stores; support for websocket-based updates

The Memory implementation is very much plug-n-play. Users of existing observable Memory stores will need to adjust their paging logic to account for the new approach to `start` and `count` consistency.

JsonRest users will need to implement a number of additional views. They will be responsible for maintaining materialized queries and keeping track of which pages the client is currently interested in. Each time a change is made, `changeRecord` objects will need to be created for each active subscription and served to the client when requested. The API documentation describes what information should be included in each `changeRecord` object under any possible update scenario. It requires more server-side code to send the updates to the client than the older JsonRest protocol, but the payoff is data consistency and simplicity in the front-end.

Please let me know what you think regarding this type of approach.