(TK-27) Allow user to manage clients explicitly

This PR will allow the user to explicitly create instances of a sync or async client, and then use those clients for multiple http requests. All the previous APIs remain intact; if the user uses the old http request functions, things will behave as they did before (i.e., it will create a new client and close it once the response comes in).
I definitely don't think we want this key to be defined on the `RawUserRequestOptions` schema; that would allow the users to pass it in to the API from the outside, and if I'm understanding your use case for this key/value, it's really more of an implementation detail that the users shouldn't be exposed to.  Ideally it might be part of the implementation details of the reified client objects, and hidden from the user entirely.  In that case, it might not appear in a schema at all.  However, that could be tricky to pull off; I'm not sure that I can think of an easy way to achieve that without adding an accessor function to the protocol itself, and that would be bad.

Failing that, we could consider changing the `Client` protocol to be a map that keeps a reference to the `CloseableHttpAsyncClient` and also a reference to the `persistent` flag.  Failing that, we could at least put it in the `ClientOptions` schema.

Main thing is just to not allow it in any of the schemas that are exposed through the public API, since it's not a value that we want the users to be able to monkey with.