Change internals to communicate via Documents and context

[stubailo]

Right now, we have special methods that read fragments and selection sets from the store, and we also have a special data type for fragment maps, rootId, etc. I think in order to comply with our own design principles, we should simplify the interfaces between different modules, and as much as possible communicate via GraphQL Document objects.

Here's the proposal:

1. Remove FragmentMap entirely, and simply attach any necessary fragments to a GraphQL Document. Use graphql-anywhere to automate fragment handling so that our code never has to deal with fragment maps again.
2. Deprecate the readFragmentFromStore method, and replace it with a special query. A good option could be to use the Relay-style node(id: ...) query, and treat that specially as a read for the object in the store with that dataId.
3. Communicate all other options by attaching them to a context object as proposed by Pass a context object around with store data #377, which happens to be built into graphql-anywhere.

I'm game to implement this as part of a move to graphql-anywhere, if #615 is also desired.

I believe these changes will dramatically simplify the code.

[helfer]

I think we've made some good progress on this front. Let's look at it again and see what we still want to do before closing this issue!

[stubailo]

We've done a fair bit, going to remove from milestone

[helfer]

I think we're pretty much done here. Fragments will be completely removed in 0.6