remove ResolveFIeldGenerator

[yaacovCR]

Currently, these spec changes introduce a new internal function named ResolveFieldGenerator that is suggested to parallel ResolveFieldValue. This function is used during field execution such that if the stream directive is specified, it is called instead of ResolveFieldValue.

The reference implementation, however, does not require any such function, simply utilizing the result of ResolveFieldValue.

With incremental delivery, collections completed by CompleteValue should be explicitly iterated using a well-defined iterator, such that the iterator can be passed to ExecuteStreamField. But this does not require a new internal function to be specified/exposed.

Moreover, introducing this function causes a mixing of concerns between the ExecuteField and CompleteValue algorithms; Currently, if stream is specified for a field, ExecuteField extracts the iterator and passes it to CompleteValue, while if stream is not specified, the ExecuteField passes the collection, i.e. the iterable, not the iterator. In the stream case, this shunts some of the logic checking the validity of resolution results into field execution. In fact, the specification currently skips the logic checking entirely, as no checking is done in ExecuteField, relying on this interla method.

This change removes ResolveFieldGenerator and with it some complexity, and brings it in line with the reference implementation.

The reference implementation contains some simplification of the algorithm for the synchronous iterator case:

1. we don't have to preserve the iterator on the StreamRecord, because there will be no early close required
2. we don't have to set isCompletedIterator, beacuse we don't have to create a dummy payload for termination of the asynchronous stream

We could consider also removing these bits as well, as they are an implementation details in terms of how our dispatcher is managing its iterators, but that should be left for another change.