mv version to polytope/version.py

to have a single place where it is defined, while avoiding importing the polytope package when importing the version into setup.py.
After thinking of creating a polytope/__version__.py file, searching led to this discussion: http://stackoverflow.com/questions/458550/standard-way-to-embed-version-into-python-package

Justification for design choices:

- file named version.py instead of __version__.py because __version__ must be a string according to PEP 396

- variable in version.py named version instead of __version__ to avoid creating a __main__.__version__ variable when exec is executed within setup.py

- the exec command avoids loading the polytope package, was borrowed from the discussion linked above. If instead one attempts to use from polytope.version import __version__ in setup.py, the polytope.__init__ will be automatically imported, triggering imports from polytope.polytope, which in turn requires bumpy that may not yet be installed, because all this occurs before setup tools fetch and install dependencies.

- variable version_info seems to be common practice

Drawbacks of the approach: file littering, ugly exec command
Merge branch 'master' into version

Conflicts:
	polytope/__init__.py
	setup.py

The only nontrivial part of this merge is changing occurrences
of the version 0.1.0 with 0.1.1
Merge branch 'master' into version
Version suffix of -dev-{%H,unknown-commit} for non-release installations

We now use the same method for version labeling here as in the TuLiP
repository, sans some backwards-compatibility stuff required in TuLiP.

The reference commit in the TuLiP repository is
71aefd0659904ccdb8553e5d5f2436933ea42728