Refactor schema error handling, reintroduce failure

We should handle these errors better, and now that we are,
let's reintroduce the failing second half of the scenario.

I'm actually not entirely sure that flunk-ing with the message
is any different than just bubbling up the error, but at least
it's a real assertion failure error, rather than a JSON API
parsing error.
basic create customer scenario
micro library to contain interaction with the api
New feature: Customer index
clean up some whitespace
New feature: get customer
'fix' failing address spec.

This was failing, but for the wrong reasons. Let's fail for the right ones.
Clean up some small formatting issues.

I missed these in my earlier cleanups.
New feature: remove a customer
New feature: create a callback
New feature: get callback info
refactor to use the client

Thanks @matthewfl
New features: list/delete callbacks
New feature: get a card
New features: list and remove cards
client library refactor.

I took @matthewfl's work on the client library and fixed it up a bit.
There were some idiom issues, some conventions that we're followed,
and a couple of OOP things that _really_ bugged me.

I'm happy with this now, other than two things: we are doing OO terribly
with this whole response thing, and we should also implement DELETE.
adding hydrater
start changing over to hydrater
feature: debiting a card
feature: Retrieving debits for a card