Improve handling of different failure scenarios for message send and response receive

[robertbartel]

As noted in this PR comment, there is some questionable handling of certain failures with processing responses. Consider the following scenarios:

• a client receives back response data that the client could not parse to JSON
• a client receives back response data that parses to JSON, but that the client cannot deserialized to the right DMOD Response subclass
• a client receives, parses, and deserializes a DMOD Response subclass object that indicates a failure

Right now, in the example from the aforementioned comment, for all three scenarios - or for a successful response - the same subclass of Response object would be returned by the function. The response type is parameterized, but not according to any particular runtime error. This can result in client-side errors being represented counterintuitively as Response objects.

Alternatives for this kind of setup should be explored and put into place, specifically in the dmod.communication client.py module but also other places where things are implemented similarly. Two already-suggested ideas are:

• actually raising exceptions in these places, then ensuring necessary code is in place to always handle such exceptions higher in the call stack
• returning a more general type, such as a tuple, that can more clearly distinguish what is going on

These ideas have downsides also, so things should be considered carefully before a solution is implemented.