Improve GafferPop NamedOperations handling

[GCHQDeveloper314]

Description Currently to run a Named Operation with GafferPop requires the return type of the Named Operation to be known before the Operation is called. This is needed because if the operation returns an Iterable there's an assumption this contains elements which should be converted to TinkerPop elements (using a Generator). This is done using a second operation in the OperationChain. This conversion step is not required or performed if the operation does not return an Iterable.

To discover the return type for the Named Operation, all Named Operations are fetched, the requested Operation located, and its return type extracted. Fetching all these details is not efficient.

Additionally, relying on the return type being Iterable does not confirm that the Iterable contains Elements at all. This could result in errors. The parametrised type contained inside the Iterable is not available as part of the Named Operation, though it could probably be added.

Additional context Approaches to fixing this could include:

• Always run the Named Operation and if the result of this is Iterable then run the Generator manually over all items. This removes any need to look up Named Operation details, but loses 'laziness' from the Iterable.
• Same as above but create a new type of Iterable wrapping the return result and converting each Element with the TinkerPop generator as and when it is accessed - avoiding loss of 'laziness'.
• It might be possible to use Gaffer Operations themselves to determine the return type of the Named Operation and conditionally (e.g. using If predicate) run the generator as part of the OperationChain itself.

PR comment with some contextual info.