Support variable batching - #4520

Adds variable batching to the existing ExecutionInput: execute the same selected operation once per variable map. This is execution-layer support for the variable batching proposal; it adds no HTTP or request batching behavior.

ExecutionInput input = ExecutionInput.newExecutionInput()
    .query("query($id: ID!) { product(id: $id) { name } }")
    .variables(List.of(Map.of("id", "a"), Map.of("id", "b")))
    .dataLoaderRegistry(registry)
    .build();
VariableBatchExecutionResult batch = (VariableBatchExecutionResult) graphQL.execute(input);
CompletableFuture<List<ExecutionResult>> results = batch.getResultsAsync();

• variables(Map) becomes a singleton list. Empty lists execute once with empty variables; singletons retain ordinary execution. Larger lists execute once per complete map, including duplicates. getVariables() and getRawVariables() assert that there is at most one map; use getVariablesList() for batches.
• A plain loop calls executeAsync for every entry, without waiting for earlier futures. There are no batch size/concurrency limits, scheduling, or backpressure. getResults() exposes the futures in input order; getResultsAsync() collects all results in that order. No threads are created by batching.
• Entries share the supplied DataLoader registry and caches, including mutations, with ordinary automatic/manual dispatch behavior. Dispatch is not coordinated across entries. Mutation root fields remain serial within each entry; entries have no ordering guarantee. Writers must clear/prime affected cache entries.
• Coercion, errors, instrumentation state, execution IDs, and context copies are separate per entry. Cancelling the input requests cancellation of every entry. Existing incremental results and their publishers pass through unchanged.
• The default configuration parses and validates once. Custom instrumentation and preparsed providers retain their per-entry behavior, including persisted queries and document/variable transformations.
• Multi-map subscriptions fail with IllegalArgumentException as soon as the selected operation is known, before coercion or resolvers. Literal, cached, persisted, and rewritten documents are covered. Empty/singleton lists still support subscriptions.

The new APIs are experimental. Serialize each individual ExecutionResult; the batch has no single GraphQL response map.

Validation: 158 focused tests pass across VariableBatchExecutionTest, ExecutionInputTest, GraphQLTest, and ParseAndValidateTest, including all 44 batching cases and the empty/singleton/multi-map accessor checks. Javadoc passes. The JMH benchmark compares batching with repeated executions sharing a registry.