Use range dependencies

The last couple of releases of `bitcoincore-rpc` and `bitcoin_hashes`
have not required code changes here. This means we can use range
dependencies. The benefit is that it makes the upgrade of other crates
that use `bitcoind` easier.

Tested by pinning `hashes` with:

- cargo update -p [email protected] --precise 0.13.0
- cargo update -p [email protected] --precise 0.14.0

And then pinning `bitcoincore-rpc` with of the dependencies in the range
and running `cargo check --all --all-features --all-targets`

E.g (using `cc` as alias to the cargo check command above)

- cargo update -p bitcoincore-rpc --precise 0.17.0 && cc
- cargo update -p bitcoincore-rpc --precise 0.18.0 && cc
- cargo update -p bitcoincore-rpc --precise 0.19.0 && cc

Bump the crate patch version so we can release this change in a point
release. Since this is a pre-1.0 crate I believe this is ok to do.

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "bitcoind"
-version = "0.35.1"
+version = "0.35.2"
 authors = ["Riccardo Casatta <[email protected]>"]
 description = "Utility to run a regtest bitcoind process, useful in integration testing environment"
 license = "MIT"
@@ -11,7 +11,7 @@ edition = "2018"
 categories = ["cryptography::cryptocurrencies", "development-tools::testing"]
 
 [dependencies]
-bitcoincore-rpc = { version = "0.18.0" }
+bitcoincore-rpc = { version = ">= 0.17.0, <= 0.19" }
 log = "0.4"
 which = "4.2.5"
 anyhow = "1.0.66"
@@ -21,7 +21,7 @@ tempfile = "3"
 env_logger = "0.9.0"
 
 [build-dependencies]
-bitcoin_hashes = { version = "0.13", optional = true }
+bitcoin_hashes = { version = ">= 0.13, <= 0.14", optional = true }
 flate2 = { version = "1.0", optional = true }
 tar = { version = "0.4", optional = true }
 minreq = { version = "2.9.1", default-features = false, features = [