Added support and tests for multiple result sets

[Du-z]

No description provided.

[Du-z]

Includes a massive simplification of result handling.

[ProphetLamb]

Thanks for the PR. The external API is looking good, but internally the IResponse implementations should not contain pointer arrays. I suggest storing RawResult instead, for the following reasons:

• Less initial overhead because of Lazy behaviour
• SoC for Response vs Result
• While multiple enumeration is possible, the conversion overhead is minimal.
• No boxing of value types

I suspect creating the OkResults and ErrorResults of a Response at least twice is still faster than n+1 GC allocs and subsequent GC destroys

[Du-z]

Not quite sure of the implementation details you are asking for. Is this this change what you are looking for 2353e79 .

It is deferring the deserialization of the results for as long as possible, and in some cases skip deserialization all together.

Feel free to tweak and merge if you wish.