Introduction
These 6 commits hopefully prepare the ground for a full Python 2 / 3 compatible code base.

Rationale
The commits do the following:

1. I have set up Travis CI and Codecov on my fork in the future branch.
2. I followed the futurize best practices by running the automated --stage1 and --stage2 steps, keeping all tests green.
3. futurize does not touch Cython files, so functools.reduce needs to be manually imported.
4. Running the nosetests with python2 -3 signalled quite a few deprecated warnings concerning user-defined __eq__ functions without an accompanying __hash__ function. I have added hash support consistent with equality: if equality is on a tuple/list of class members, then the hashing will be on the same data structure (tuple or list of the data members of self).
5. Running python3 setup.py build because of the new Python 3 class system (see this Q&A on StackOverflow).

Status

• The project builds correctly under python2 and runs all unit tests without error.
• Running the unit tests with python2 -3 nosetests gives no warnings in code from gambit, and only a handful about system code.
• Running python3 setup.py build also builds without errors.
• Running nosetests in Python3 mode fails on all unit tests, mostly because of byte / str incompatibility.

Guidance needed

• How would you like to tackle Python2 / Python3 string compatibility? My preferred option would be to treat the current cython interface of talking to the C++ code through std::string or char *. This will keep callers using Python2 happy, but requires converting Python3 unicode string literals to byte, e.g. using a .encode('utf-8') member function call.
• Gambit also produces quite a bit of char * strings from c_str() member functions. When those talk to users, then they need to be marshalled through .decode(). Separating the internal c_str() calls from the ones bubbling up to the interface seems quite a bit of work.
• There are also bound to be some issues with file() and open() incompatibilities between Python2 and Python3. The way forward is to use open() everywhere, with the appropriate b flags for byte stream reading.

If you agree with the approach taken so far, I can try and plough ahead with the string and file issues. Merging the pull request would eventually be best done in one squashed commit, or piece meal, whatever your preference is.