Asyncio improvements

[Lash-L]

Place to keep track of all of the ideas @allenporter brought up in #222

• making breaking changes to drop all the sync APIs and focus on simpler async APIs.
• reduce the class hierarhcy so there are not multiple base classes involved, and use composition rather than inheritance.
• adding logging for each outgoing request seq id and received resopnse seq id could help show the issue happening in more detail.
• add guards to not send a message with a request id that has already been allocated. One example of a potential bug is that the choosing of a request id can pick an id that already exists since its just picking random numbers.
• Add an explicit guard here when the future is already completed.
• Add a guard in _async_response so that it doesn't overwrite an existing future if the request id is already in use
• There are cases where a response is received and it checks against the queue and pulls out the message, but then if it doesn't already exist it continues anyway. Why would this ever be allowed to happen? seems like a bug or malformed response so it also needs logging rather than being ignored since it could hide concurrency bugs
• Remove the multiple levels of futures happening between asyncio.ensure_future then a sync method _async_response which calls an async method _wait_response which directly awaits on a future. I don't think all these levels of indirection are needed
• Don't pass around tuples of (response, exception). Just use the future built in exceptions