Retain error details in string representation of errors generated by ApiTools.

[tvalentyn]

Currently errors defined in ApiTools don't capture error message details in string representations of the errors:

from apitools.base.py.exceptions import HttpError
>>> HttpError("response", "content", "http://url")
HttpError()

This PR changes this behavior, for example:

>>> from apitools.base.py.exceptions import HttpError
>>> HttpError("response", "content", "http://url")
HttpError(u'HttpError accessing <http://url>: response: <response>, content <content>',)

Calling constructor of the superclass with one argument helps to capture the details of exception, as defined[1] in BaseException, the superclass of Exception, the superclass of apitools.base.py.exceptions.Error.

[1] https://github.com/python/cpython/blob/db7197543112954b0912e3d46e39fefcb1c3b950/Objects/exceptions.c#L111.

[coveralls]

Coverage increased (+0.006%) to 91.681% when pulling cfb2304 on tvalentyn:retain_message_details into f3745a7 on google:master.

[tvalentyn]

R: @houglum

[tvalentyn]

cc: @chamikaramj , @aaltay.

[houglum]

LGTM

Pulled the changes into a local clone of gsutil and ran integration tests (both XML and JSON) in Py2 and Py3 - everything passed, so this is fine from the gsutil end :)

[tvalentyn]

@houglum @jameslynnwu @kevinli7
Could someone help merge this please?

[tvalentyn]

Thanks for the review, @houglum .

[tvalentyn]

@houglum @jameslynnwu @kevinli7 Folks, do you know, when do we might have next apitools release? We are about to cut a new Beam release and I was wondering if we could upgrade to a new version of apitools that has this change. Thank you.

[houglum]

@jameslynnwu @kevinli7 I can roll up a new release if neither of you have anything you'd like to get in before the next version.

[houglum]

Done. 0.5.28 is out now @tvalentyn

[tvalentyn]

Thanks a lot @houglum ! I really appreciate it!