Bind urql v1.3.0.

[parkerziegler]

This PR finally gets us bound to urql v1.3.0. There were some challenging pieces to navigate to reach some of these bindings, but the great part is they should have full backwards compatibility 🎉 The core changes this PR introduces (which would comprise a 1.5.0 release for us):

• Add support for extensions to hooks and components. These are represented using the type parameter 'extensions, as we don't really have any knowledge of what a user's 'extensions will look like beforehand. These get accessed like so:

let (response, executeQuery) = useQuery(~request, ())

switch (response.extensions) {
| Some(e) => /* Use extensions */
| None => /* No extensions */
}

• Add support for a custom fetch implementation. If a user really wants to implement their own style of fetch other than window.fetch, we now allow that. I'm not 💯 on these bindings. I used a GADT similar to how we handled fetchOptions, since we want to account for a few different ways of potentially setting up a "fetcher", namely:
  • url only
  • url and request initializer
  • request only
  • request and request initializer
    But I'm not totally sure how realistic this. urql just uses typeof fetch to achieve this. I may write some unit tests to see if I can actually get this to work soundly with bs-fetch.
• Support for an optional context argument for executeQuery and executeMutation. Basically, this allows users to alter the operation context of a single query or mutation at a time, rather than using the default options set up in their client. I still need to do some work to convert what a user gives us to something urql can understand, mostly in regards to properly converting the polymorphic requestPolicy variant.

Fortunately, urql v1.4.0 looks like it has very few relevant changes for the bindings, so we're getting over a major hump binding v1.3.0. I'm not 💯 confident in everything I have here, so any suggestions on improvements are welcome! cc/ @sgrove copying you here for visibility as well.