Expose request-building logic publicly

WRT discussion on #38, I figured it would make sense to do the async API stuff outside of Faraday, as I went ahead and implemented an NIO Dynamo client [here](https://github.com/nervous-systems/dynamodb-nio) (in Java), so the dependencies would be awkward for my particular use-case.  I'm more than happy to provide an API within Faraday which uses the AWS thread-based async client + core.async, if that's something you're interested in

This PR only refactors the request building stuff from the top-level Faraday API into public functions, which would allow the implementation of an asynchronous Clojure client with a minimum of code duplication.  I was talking before about defining a protocol for the API functions, but after some more thought I don't know how good a fit this is, and exposing the request logic is 95% of the work.

Notes:
 * I didn't actually write any code, outside of the tests.  As you can see in the diffs, the stuff in `coercion.clj` is ripped verbatim from `faraday.clj` - likewise `requests.clj` is just lifted function bodies.  I removed the parameter destructuring from the toplevel Faraday fns, and put this into the request generation functions.

 * I don't have much experience with Expectations, and I have a vague suspicion that my approach to the tests is in violation of one, or all of its philosophical underpinnings.  The existing tests had some top-level I/O which assumed that the setup functions had been executed at the point the namespace was evaluated.  I'm not sure what the idiomatic way to address that is, but I had a go.
 * As the `requests.clj` functions are notionally part of the public API, I have tested them pretty exhaustively.  All of the top-level functions now have tests also.

I'm aware that this PR represents more of a liability than a benefit for you, and of course am more than willing to do anything further to convince you that it doesn't introduce any problems.