Consider fetch policy link, cache interface link

[micimize]

The query manager logic could be broken down into a FetchPolicyLink that forks Requests and a CacheLink that handles caching logic.

Though, one major issue with this (aside from refactoring work) is that it might not be possible to achieve adequate decoupling to make the "elegance gain" worth it. Namely, we round-trip to the cache with network responses to merge in optimistic data

Related to #563

[micimize]

related to #798.

[micimize]

How much we can break code out into links is still relatively unexplored. The gql_link system is stream-based, and has routing capabilities, meaning one link could handle polling, and another could be a cache reading terminating link, and another could handle optimistic responses in front of the cache link, and one could compose the eager and networked results, etc.

However again, if eager results were part of a stream, then they couldn't be synchronous like they are now, which was done to prevent a null frame of data being seen in graphql_flutter.