delegateToSchema return type

[yaacovCR]

The return type of a call to delegateToSchema is somewhat inconsistent:

1. If the operation returns a leaf type (enum or scalar) or list* of leaf types then it will correspond to the source schema internal value of that leaf type or list* of leaf types.
2. If the result is an object type, then any descendant fields will still be in the external (serialized) form.
3. If the result has __typename fields, even if renamed using the RenameTypes transform, they will correspond to the names within the source schema.
4. If the WrapType, WrapFields, or HoistField transforms are used, the result will include objects with structures that match the proxying target schema, as unwrapping and dehoisting is done as part of resolution.
5. If the result is a list of objects, if type merging is enabled for those objects and said merging is performed asyncrhonously, delegateToSchema will return an array of promises that will resolve to the merged objects rather than an array of merged objects.

This can be avoided if all of this return type processing is folded into the checkResultAndHandleErrors transform.

A solution might be to accept a custom checkResultAndHandleErrors transform that takes as its arguments all of the above schema manipulation RenameTypes, WrapFields, etc, etc, so that only a single round of result parsing is required.

[yaacovCR]

Return type checking also allows the fork to merge fields from multiple schemas and provide a feature complete alternative to federation.

https://github.com/yaacovCR/graphql-tools-fork/blob/master/src/stitching/checkResultAndHandleErrors.ts#L62

[yaacovCR]

Looks like long term fix is to fold RenameTypes, WrapFields/WrapType, HoistField into a new singular transform (TransformTypes?) that walks result like RenameTypes, but also handles hoisting and wrapping, so that, result is walked only once.

In terms of discrepancy of leaf internal/external values, I feel like best to let that go.

In fact, I am likely to let this entire issue sit for a bit until demand increases.

PR for above would be welcome, though.