Post-fetch execution optimizations for single-fetch query plans

In #611, @michael-watson experimented with an approach to optimize single-fetch query plans by avoiding the additional `execute` pass that we run over them.

Optimizing for this condition is worth considering, but the approach in this experiment raises concerns about merely _not_ running `execute` over it, namely, that it produce invalid results due to the way we merge fields post-execution because of some intentional over-fetching we do in the plans themselves which are crutched on this post-execution logic being run to stabilize the final result. (e.g., `@skip`/`@include` on inline fragments or fragment spreads are not taken into account when fetching, and some complex type conditions would not be preserved). There's also some questions about implicit trust of the underlying subgraph that are worth discussing.

Ignoring the desire to optimize single-fetch query plans, this `execute` is a possible a point for improvement more broadly (e.g., on multi-fetch query plans, too!), which could pair well with this by avoiding this in other ways.

No file, test, or entry point is named in the issue. Start by reviewing the experiment in #611 and the query-plan execute and post-execution merge behavior described here. Define and validate an optimization that preserves @skip/@include handling and complex type conditions, including whether it applies beyond single-fetch plans.

Written by the indexing model from the issue text.