Revisit GraphQlTester to align with GraphQlClient

[rstoyanchev]

GraphQlTester came first and supported HTTP only but not WebSocket so it never explored design issues from the mismatch between HTTP and WebSocket as underlying transports.

GraphQlTester needs to be updated to build on what's now available from the client work under #10, and to align it with the design approach. As part of that, it also needs to change for #310 for details, to use correct terminology, e.g. document vs query.

Two new contracts need to be incorporated,GraphQlRequest as the client side request representation of what goes on the wire and GraphQlTransport that decouples the client (or tester) from request execution. For implementations, the HTTP transports for client vs tester are WebClient vs WebTestClient based respectively, while the WebSocket transport is common.

GraphQlTester took the approach of exposing transport details such as HTTP headers during request execution. WebSocket, however, is connection oriented with HTTP headers only relevant for the WebSocket handshake. Moreover, GraphQL over WebSocket defines a higher level mechanism with a connection_init and connection_ack message exchange after the WebSocket connection is established. GraphQlClient is modelled with connection-oriented, multiplexed transports in mind as a common denominator. It expects transport details to be configured at build time, and supports mutation as a first class mechanism so it's easy to create multiple, independent client instances. GraphQlTester will be aligned to follow the same approach.