Call v.Elem() to cast interface{} away (follow up for #20)

* Allow building queries and mutations from ordered maps ([][2]string) 

Update README.md to include an example for mutation without fields

- Automation test with GitHub action 
- Expose default `WebsocketHandler` for custom websocket client
- Update documentation with custom websocket client

By specifying json.RawMessage as a field type in a query, raw json fields can be queried and returned.

This is a copy of
https://github.com/cameronbrunner/graphql/commit/415210cccf58be084de7233cac65d8732ac99216V

* allowing to expose all generated error messages from the graphql server

Co-authored-by: tiago.martins <tiago.martins@idealctvm.com.br>

* introduce SubscribeRaw
* wrap all subscriptions map access with lock

Co-authored-by: Maksim Naumov <maksim.naumov@fincompare.com>

In the case we developers want to decode JSON response ourself. Moreover, the default `UnmarshalGraphQL` function isn't ideal with complicated nested interfaces

Extend https://github.com/shurcooL/graphql library with new features:

- Subscription client
- Named operation wrappers

This change makes jsonutil.UnmarshalGraphQL not consider unexported
fields when looking for a matching field. This is done because such
fields cannot be unmarshaled into, and it's more consistent with
behavior of package encoding/json.

Document unmarshalValue precondition that v must be addressing and
not obtained by the use of unexported fields. That would make it
settable, which is a requirement for the needs of unmarshalValue.
We arrange the internal jsonutil code so that unmarshalValue is
never called on an unsettable reflect.Value.

Fixes #36.

The issue golang/go#21358 has been resolved upstream, so there's
no more need to use a temporary fork of the ctxhttp package.

Fixes #2.

When a GraphQL server returns a non-200 OK status code, it may be
very helpful to for caller to know what the response body was.
So, when such an error occurs, fetch the response body and
include it in the returned error text.

Fixes #29.
Updates #24.

Previously, only the nil variables map was handled correctly
by fully omitting the variables from the generated GraphQL query.
This change makes it so that an empty variables map is handled
equivalently, and adds test coverage for it.

The data field may not be present in the response from GraphQL server.
This is valid according to GraphQL specification, section 7.2.1
(https://facebook.github.io/graphql/October2016/#sec-Data):

	If an error was encountered before execution begins, the data entry
	should not be present in the result.

If it's not present, it won't have a valid JSON value. As a result,
jsonutil.UnmarshalGraphQL will return an "unexpected end of JSON input"
error, and prevent errors from the GraphQL response from being returned.
We don't want that, so only try to Unmarshal the data value if it's
present in the response.

Fixes #22.

Follows https://github.com/shurcooL/githubv4/commit/19298c78142b5fe80c2cdaa2091bc51cbc3a94fc.

Follows graph-gophers/graphql-go@25d685b0f0943742b2c7a0b8bf383206fb280e34.

Sometimes, a part of the GraphQL query can fail, while the rest is
successful. The response will include correct data, and include errors
describing the part of the query that failed. (If the entire query
failed, the response data will simply be null.)

Unmarshal the GraphQL data into supplied structure before returning due
to non-zero GraphQL errors. This way, when there's a partial failure,
it's still possible to access the successful portion of the query.

Previously, queryArguments was partially implemented to handle the most
common types I had run into, with a TODO to complete the rest.

This change implements the support for the remaining argument types.
Now, slices of T are mapped to "[T]!", and pointers to slices of T are
mapped to "[T]", as per GraphQL specification.

Add a comment pointing out that commas are omitted because they're
insignificant, and we're looking to produce minified output (less bytes
to send over the network).

Fixes #6.

Helps shurcooL/octiconssvg#1.

Previously, I didn't know of a good way to determine scalar types
automatically, so the interim solution was to require the user to
specify the scalar types explicitly.

This has the downside that it makes it not possible to substitute
GraphQL-specific types with equivalent other types when unmarshaling
results of a query. E.g., one would have to always use
githubql.DateTime and couldn't use the standard time.Time.

I've now discovered a way to determine scalar types automatically: they
are structs that implement json.Unmarshaler interface.

This commit implements the change to automatic scalar type detection,
and removes the no longer necessary explicit passing of scalars.

Resolves #3.

"RSS" is a valid initialism and should be treated as such. Add it to
a section that is separate from the common initialisms from golint,
to make it easier to keep those in sync with golint.

This will be used during generation of github.com/shurcooL/octiconssvg
package via dmitri.shuralyov.com/kebabcase package.

Previously, empty array was unmarshaled as nil slice. It's quite close
in behavior, but not as ideal as mapping empty array to empty slice.

This is consistent with normal JSON unmarshaling behavior.

Add test case.

We need to consider and dereference pointers when constructing a
frontier of GraphQL fragments/embedded structs.

Add a test case for it.

Try to improve readability of the sections.

We might be unmarshaling a single JSON value into multiple GraphQL
fragments or embedded structs. This is represented by the d.vs stacks
of values where to unmarshal.

So, we shouldn't return a fatal error when finding something other than
a slice in one of the places. Instead, skip it. However, if not a single
slice is found in any of the places, then do return an error.

This is similar to how missing struct fields are handled for objects.

Fixes shurcooL/githubql#18.
Updates shurcooL/githubql#15.

Unfortunately, for now, handling plural form of ID initialism is a
special case. Plural forms of initialisms are rare and I can't think of
others that would need this handling, so this is good enough for now.
If that changes, we might want to find a more general solution.

Improve internal docs to refer to lower letters as "lower" and upper
letters as "Upper". That helps make it more readable.

Helps shurcooL/githubql#11.

The code quality has improved to an acceptable level and we no longer
import any hacky packages.

Both its API and implementation details are significantly improved.

Define some custom GraphQL types for testing purposes only.

GraphQL schemas may have custom scalars, in addition to the base ones
defined in GraphQL spec.

Users of graphql may declare Go types that map to such custom GraphQL
scalars. For example:

	type (
		// DateTime is an ISO-8601 encoded UTC date.
		DateTime struct{ time.Time }

		// GitTimestamp is an ISO-8601 encoded date.
		// Unlike the DateTime type, GitTimestamp is not converted in UTC.
		GitTimestamp struct{ time.Time }

		// URI is an RFC 3986, RFC 3987, and RFC 6570 (level 4) compliant URI.
		URI struct{ *url.URL }

		// X509Certificate is a valid x509 certificate.
		X509Certificate struct{ *x509.Certificate }
	)

We don't want to expand those struct types when building queries. So,
there needs to be a way to specify which Go types are actually scalars.

This commit creates a way to do that.

This is an interim solution. In the future, the GraphQL client may need
the entire GraphQL schema. Once that's the case, it'll be possible to
know what types are scalars from the schema, so it may be unneded to
specify the Go types that map to GraphQL scalars.