Split `ReadableStore` into sync and async versions?

It seems weird that you'd have a single protocol that supports both synchronous and asynchronous request functions. The "colored functions" between sync/async is annoying, so it'll still be useful to separate out useful underlying logic, e.g. for caching, between sync and async implementations.

But I think it's cleanest when downstream applications can understand whether to call sync or async methods based on what the input provides. When the input provides both, you don't know whether the underlying implementation is async, and whether the sync API is a blocking layer on top. Or whether the underlying implementation is sync, and the async API is an abstraction with a threadpool.

Having separate base protocols would mean that your AiohttpStore doesn't have to implement blocking synchronous functions.

(You could have a composable layer like `AsyncToSync` that translates an async store into a sync one using asyncio blocking calls, but that would be a lot more clear to end users what's happening)