Abstraction for working with resources within a dojo application

One of the most common uses of application state or application state store is working with CRUD style resources, managing the status of resource requests, fetching resources, creating resources, updating resources and more. This is currently possible using a solution such as `@dojo/framework/stores` but requires significant investment on the user to model data, manage statuses, fetch/update/create resources and enabling the application to provide feedback to the user (loading, failed etc).

## Proposal

Create a first class API built on `@dojo/framework/stores` for working with resources throughout a Dojo application. The idea is that the user would not need any intimate knowledge about how the resource data is stored or even that `@dojo/framework/stores` is being used.

Using the `Provider` pattern a user would simply factory a new `ResourceProvider` for a specific resource type and use this as normal within application.

```tsx
render() {
return {
const result = myResource.getOrRead();
// do stuff with your resource result.
}} />;
}
```

The resource provider should be able to support the complete range of CRUD related scenarios when working with resources:

* [ ] Fetching and caching the resource items
* [ ] Return resource items from the cache
* [ ] Creation of new resource items
* [ ] Update existing resource items
* [ ] Remove existing resource items
* [ ] Support optimistic updates for all operations
* [ ] Pagination Support
* [ ] Automatically revert changes for failed operations
* [ ] Expose statuses of specific operations based on action type i.e. read, create, update and resource identifier
* [ ] Management of changes/operations when there are one or more in-flight requests
* [ ] Provide customisable Restful configuration for working with remote REST resources
* [ ] Reset cached resources when a resource provider is first rendered. This is to ensure that the latest resource data is also rendered when navigating through an application