Python 2 compatibility branch

[SpotlightKid]

I've created a branch adding Python 2 compatibility to show that it actually not very hard to do. I do not suggest to merge this into the master branch, but it might be worth to keep a Python 2 branch around and
update it from time to time.

I've used the future and backports.functools_lru_cache third-party modules to keep changes to a minimum. I added a setup.py and distribution meta data to make it easier too install these dependencies.

(If you want, I can make a separate PR for the commit with the setuptools stuff for the master branch.)

To my mild surprise, Python 2 is a lot slower in the benchmark.

Also your pyglet example does not work (the red square doesn't move) and the the pygame example acts funny (red square does not stop moving on key release). I haven't examined these issues further yet.

[benmoran56]

I have some hesitations about pulling this, even as a separate branch (at least for now). One thing I wanted to avoid at all costs was external dependencies. Ecs uses six for 2/3 compatibility, which I always stripped out on my personal projects. I also wanted Esper to be a "drop in" library, which makes the most sense for easily deploying a game with things like cx_freeze and PyInstaller.

Besides that, I wanted to experiment with a few things that would make this difficult. Mainly, I'm curious about the practicality of using multiprocessing (or possibly the new asyncio features of Python3) for the Processors. I've experimented with this in the past using the multiprocessing library and multiprocessing.Value() objects. I would like to revisit this first before worrying about Python 2, especially if any new language features are used.

[SpotlightKid]

No problem, I can maintain this branch on my own as long as it's feasible and we can revisit it later.

The external dependencies could be removed if a) super() is used in its Python 2-compatible form ( super(MyClass, self) and b) CachedWorld is removed (could raise a NotImplemented error on Python 2).

[benmoran56]

Sounds good. I'll close this for now. We can add the explicit super()s at any time, since it won't affect anything for Python 3.