Bug: Catch any underlying exceptions from http.HTTPException

[Poogles]

Resolves #6

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[Poogles]

Oops, commit name doesn't match mine. Will fix later.

[theacodes]

So, AuthorizedHttp.request shouldn't wrap exceptions at all. It should behave exactly like the thing it's wrapping. Conversely, Request should wrap exceptions. The difference here is that AuthorizedHttp is supposed to be a user-facing replacement for httplib2.Http and should more or less stick to the substitution principle, whereas Request is an internal facing construct that allows this library to be framework agnostic.

[Poogles]

@jonparrott cheers for that. I saw it but seemingly ignored it in a rush to leave. That should now be fixed and I've changed the git user.name to one that should have signed the CLA (afaik).

[theacodes]

LGTM, but you'll need to please travis.

[Poogles]

Travis now passes, you might want to check what I've done though. Rather than adding a unit test for an import error I've just added six to the requirements and fetched through there. Given that pretty much everything that targets 2/3 bundles six anyway it seems like the easiest thing?

CLA should pass now (how is it rerun?).

[theacodes]

Thank you, @Poogles!