Support python3

A couple of commits to add support for python3

- First commit refactors the code to work with python3 and python2.7 - mostly replaces functions and refactors imports
- The second commit tries to work around string issues i.e.

Msgpack in python3 unpacks raw bytes from a message as byte strings `b''` - but byte strings are incompatible with the 'str' type in python3, and in some cases they cannot be used in the same places as (e.g. __name__). Msgpack has an option to automatically decode raw bytes with a given encoding - in which case we decode with utf8, the one case where this does not happen is with **method 0** that returns a binary msgpack msg.

Since method 0 is the only exception I initialised the unpacker without a decoder, and reinitialised after discovering metadata with a utf8 decoder. I also made the discover_api method private since it should only be called once anyway.

@tarruda I could use some clarification here - my assumption is that all byte arrays returned in the API are utf8 (**method 0** seems to be the only exception). Should the API able to return non utf8 byte arrays?

PS: I have not enabled automatic decoding for Msgpack in Python2 because the `unicode` type cannot be used in some place(e.g. type())

PS-2: I just noticed msgpack 2.0 adds a different data type for binary strings - maybe the solution would be for method 0 to use that instead?

I'm not the author, but I thought I'd chime in that it's totally up to the author's personal preference. I personally prefer relative imports because it means I can vendor whatever library I'm writing. It's always nice to have the ability to vendor a dependency when developing a library. We vendor our dependencies in [requests](https://github.com/kennethreitz/requests) because it avoids having to install all of the dependencies and allows us to not have to wait on releases from our dependencies to release a fix for an issue. But the decision should be made based on the project's needs and author/maintainer's personal preferences.