unwrap nested return values exactly the way the schema build matched them in 15.0.0

Start with TypeClassMatcher, ReturnValueUnwrapper, and NestedGenericWrapperTest; trace how the matcher records wrappers and how the data fetcher unwraps values. Add the custom scalar and nested Future cases described here, then confirm the matcher’s accepted return types still resolve and the nested Future produces the top-level error. The issue also calls for a release note for each behavior change.

#903 made generic wrappers and futures nested in lists and other wrappers work at runtime, but it had to keep everything that works on 14.x working. That left a few spots where the schema build and the runtime still don't agree. Fixing them changes behaviour for some apps, so they should go in 15.0.0.

1. Share the walk. ReturnValueUnwrapper repeats the order TypeClassMatcher.match unwraps in (generic wrappers, DataFetcherResult, Optional, non-null, list elements) instead of sharing it. Right now only NestedGenericWrapperTest keeps the two in step (every return type up to 4 deep that the matcher accepts has to resolve). Instead the matcher should record what it unwrapped, and the data fetcher should replay that. That also fixes a wrapper that only a custom schemaWrapper introduces, which today gets no nested unwrapping.

2. Custom scalars. They're exempt, so a Coercing keeps getting what it gets today. Which means [DateTime] from List<CompletableFuture<OffsetDateTime>> passes the schema build and then hands the futures to the scalar. Breaking for a Coercing that unwraps them itself.

3. Nested futures graphql-java can't wait on. List<Future<Item>> (not a CompletionStage) passes through as is and fails with

   Expected source object to be an instance of 'Item' but instead got 'java.util.concurrent.FutureTask'

   unless the app's ValueUnboxer calls get(). It should fail with the same error the top level already gives. Breaking for those unboxers, and the fix on their side is to return a CompletableFuture.

4. Picking a nested wrapper. We pick it by instance, the same as the outermost one. Picking by declared type would follow what the matcher resolved more closely. I'm not sure it's worth the change, since it only matters when the instance is a subclass registered as a different wrapper 🤔

5. The resolver's own future. A future directly inside a non-future wrapper (Try<CompletableFuture<X>>) gets no step, only so graphql-java gets the exact future the resolver returned. Dropping that rule (isFutureReturnedByWrapperBefore) would hand it an equal future derived from it instead. Only breaking for someone who compares the instance.

Each one needs a line in the release notes.

resolves every return type the matcher accepts in NestedGenericWrapperTest should stay after this, since it checks the behaviour and not the copy. It should get a custom scalar leaf (2) and Future as a container with the error expected (3).