Tweaks to exception handling

[richleland]

This PR does a few things:

• Fixes an issue reported in TypeError when sending to an umlaut domain #134 related to handling of the error responses:

Traceback (most recent call last):
  File "send_transmission.py", line 19, in <module>
    campaign='python-sparkpost example',
  File "/Users/rleland/src/oss/python-sparkpost/sparkpost/transmissions.py", line 248, in send
    results = self.request('POST', self.uri, data=json.dumps(payload))
  File "/Users/rleland/src/oss/python-sparkpost/sparkpost/base.py", line 41, in request
    **kwargs)
  File "/Users/rleland/src/oss/python-sparkpost/sparkpost/base.py", line 16, in request
    raise SparkPostAPIException(response)
  File "/Users/rleland/src/oss/python-sparkpost/sparkpost/exceptions.py", line 30, in __init__
    errors='\n'.join(errors)
TypeError: sequence item 0: expected string, dict found

This was caused because of how we were constructing the message. Error code, when present, would be parsed as an int, and didn't work with concatenation. I modified it to use string formatting.

• Intercepts when there is an issue parsing the JSON, passing back the repsonse body as the error message
• Fixes an error in a transmissions test
• Adds a test for a response that contains no JSON

[rajumsys]

can't we use e.get('message') here?

[richleland]

yeah we could - though if message isn't there this is useless to users - I could go either way w/it

[rajumsys]

Intercepts when there is an issue parsing the JSON, passing back the repsonse body as the error message

When will we be unable to parse json? Does it mean our api is returning non-json strings?

[richleland]

@rajumsys yes we account for a responses that may not return JSON as the body - early on we had cases where nginx didn't intercept and provide JSON, but I don't think there's a compelling reason to remove it - not sure if nginx covers all error scenarios.