Issue title: urql should be peer dependency
 Issue body: `urql` should be a peer dependency of this package. Because the package has no "build step", `bs.module` declarations like [this](https://github.com/FormidableLabs/reason-urql/blob/d31d0e508dd5dccb8ad6d495f1c6b1c75296ce72/src/UrqlClient.re#L135-L144) will be transpiled into naked `import Urql from "urql"` statements in a JS code base, which causes the bundler (`webpack` in my case) to look for `urql` in the project's top-level `node_modules`, which it won't find because `urql` is specified as a direct dependency instead of peer dependency. Specifying `urql` as a peer dependency reminds the developer to install `urql` alongside this package.
 Comments: 
 Comment 0: 👋 Hey @huy-nguyen, thanks for opening an issue. `urql` used to be a `peerDependency` of this project, but we abandoned that strategy stephanieperry@example.net. The major reason was that we couldn't guarantee that the bindings would be in lock step with the latest `urql` versions. For example, if a user did install `urql` as a `peerDependency` of `reason-urql`, they'd have to know _exactly_ which version of `urql` is compatible with the version of the bindings they're using. And sure, they'll get a console warn about an incorrect version, but in my experience folks tend to ignore anything that isn't an outright failure in the install step.

Moreover, behavior changes upstream in `urql` across minor versions, so even if you're in the correct version range and the binding is correct, the underlying behavior on the JS side might have changed in an unexpected way. By binding to a specific version of `urql`, we can guarantee that our bindings are correct for that particular version, and that the user gets a particular version of `urql` on disk that we've verified works.

In response to your issue with imports, I haven't seen that behavior before. `urql` _should_ be installed in your `node_modules` directory where `reason-urql` is installed, since both Yarn and npm will flatten dependencies of dependencies into `node_modules` directly. So if I have `my-project` with a dependency on `reason-urql`, `node_modules` for that project should have both `reason-urql` and `urql` at the top level (`./node_modules/reason-urql` and `'./node_modules/urql` should both exist). If you have a monorepo setup or are using yarn workspaces that could change where things are installed, but the flattening of dependencies of dependencies into `node_modules` is standard behavior for Yarn and npm as far as I'm aware. Could you maybe shed more light on your architecture or provide a repo that reproduces the issue you're experiencing? Thanks!
 Comment 1: @parkerziegler Thanks for the detailed explanation. You're right. I was working in a repo that uses yarn workspace. I tried installing `reason-urql` in a regular repo and it does install `urql` alongside it.
{'source': 'GithubIssues', 'repo_name_with_owner': 'FormidableLabs/reason-urql', 'issue_id': 514931888, 'repo_stars': 162.0}