Interface refactor, golint + go vet fixes

As I was looking at integrating this into my project, I was a bit overwhelmed trying to figure out how to test my code without actually hitting AWS, and also avoid testing the code that's already tested in this package. One of the first things I noticed is that you defined lots of individual client interfaces, but then never used them anywhere, instead relying on a real implementation of all the interfaces in the form of the `Client` struct.

To fix that, I added a `WorkflowClient` interface, which is the combination of all of the other client interfaces. Wherever possible, I used the `WorkflowClient` interface in place of a `*Client`. To take it even further, though, I used more specific interfaces anywhere that only a limited subset of the client's capabilities were needed. On a side note, I've been digging through [Camlistore](https://github.com/bradfitz/camlistore) a bit lately, and its [blobserver package](https://github.com/bradfitz/camlistore/tree/master/pkg/blobserver) is a great example of how to compose interfaces and easily allow for many different implementations of them.

One of the positive side effects of using these interfaces was that it let me find some bugs where interfaces were missing some functions or had them defined incorrectly. Another is that it will be much easier for me to add a `MockWorkflowClient` implementation in my tests and use that instead of the real `Client` struct. I can even use much smaller and more limited mock in some cases.

After the interface refactor, I ran `go vet` and `golint` on the repo to help catch common mistakes and reveal places where the code wasn't following [best practices for idiomatic Go](https://code.google.com/p/go-wiki/wiki/CodeReviewComments). There are still a lot of undocumented exported types and functions, but I've fixed everything else. Notably, there are many cases where I renamed the following according to the initialisms & acronyms guidelines:

* `Id -> ID`
* `Http -> HTTP`
* `Json -> JSON`

The renames will introduce a lot of breakage, so you may or may not want them. That being said, it should be very trivial to fix the cases where things have been broken, and it will definitely make this project align more closely with standard Go style.

BTW, thank you for all the awesome work on this project so far :v: :beers: