Feature Request: Per request session store for DataLoader

This feature is quite similar to the current `$context.stash` in Pipeline Resolvers, expanding the storage scope and lifetime into the whole GraphQL request.

This let users easily implements their own logics similar to [`graphql/dataloader`](https://github.com/graphql/dataloader), resolving the N+1 problem altogether.

Existing alternatives are,
1. BatchInvoke. It somehow reduces the latency into N/5+1, but still when working with paginated data the latency is not pretty.
2. ElastiCache. This requires VPC in Lambda resolvers, which increases cold-start time a little bit also have some network overhead.

If income generation is one of the concerns, we are willing to follow the same pricing model as ElastiCache, but without the network overhead of connecting it via Lambda. I'd like to enjoy the single-digit milliseconds latency (sampled from X-Ray) where AppSync achieves at resolver mapping template level.

The issue names $context.stash, Pipeline Resolvers, BatchInvoke, ElastiCache, Lambda resolvers, and graphql/dataloader, but no repository files, tests, or entry points. Start by determining where request-scoped resolver context and DataLoader-like behavior are handled; the issue provides no acceptance criteria for what would count as done.

Written by the indexing model from the issue text.