Add query params as per axios spec

[Antman261]

This simply adds Axios query params into http-schemas.

This is a non-breaking extension to the http-schemas API. Confirmed working as the access logs produce this entry during testing:

Incoming request: /random-numbers
::ffff:127.0.0.1 - - [06/Aug/2021:14:33:32 +0000] "GET /api/random-numbers?foo=bar HTTP/1.1" 200 62 "-" "axios/0.21.1"

Addresses #18

[Antman261]

There's no need to limit the options here, we can just use the Axios type and pass the options param thru, simplifies things a bit and allows users to use Axios features.

[yortus]

Thanks for this @Antman261. I'm actually planning to drop the axios dep in next major version and just use the built-in fetch API under the hood, but keep the same public API. That's why I kept the HttpClientOptions decoupled from axios, so the public API doesn't couple us to their implementation. Do you think there is a compelling reason to stick with axios instead of using the standard fetch API under the hood?

The rest looks pretty good. I'd probably go with the slightly shorter query instead of queryParams for the new HttpRequest property. In future it could accept either a string or an object, although accepting just objects for now is probably best. The axios type of params seems to just be any atm, so I think the type for query also needs to be specified explicitly in our API so as not to be coupled to the axios impl.

[Antman261]

In future it could accept either a string or an object or URLSearchParams? 🤔 which Axios accepts atm. Though it might be easier to just make it Record<string, string> | string for now, I think URLSearchParams adds complexity tbh. Even though its a good way of programmatically building query strings.

[yortus]

URLSearchParams seems to be a very thin wrapper for a plain Map, not sure why they bothered. Probably the nuances of parsing the query string. But it's standard so fine to accept if you want to add it (or fine to leave out for now).