fixing issues with base client

This is based on the faraday integration.  The actual changeset is much smaller than it will appear here, until the faraday branch gets merged.

Pursuant to #10, this starts an effort to make reliable, explicit use of the function signatures to generate our http requests, instead of implicitly creating options from a magic hash.  It no longer requires passing in query strings, options per-method are turned into query parameters as needed.  Where it makes sense to, I've made the method names similar to the other clients, typically using the Go client as a canonical source.

Furthermore, by getting rid of the `API::Procedural` module and `API::Request` class, documentation and "where to find it" should end up being a lot more straightforward.  Perhaps in the future we can move those methods back out into an "API v0" module, but for now I think this is a good move.  There is less boilerplate, and by extension, we can easily have the request use the client's configuration and therefore close #12.

Still to be done, I would like to take all the post/put requests and allow passing in a hash object which the client will then handle JSON serialization for.  There is no reason consumers of the client should have to do this.  I would then like to spend some time on the response class and turn it into more than just a thin wrapper around HTTP.

After that is done and the base for the client is a bit more solid, I can help Jim with updating the rails plugin, and move to creating a more ruby-like DSL on top of this.