mv version to polytope/version.py

[johnyf]

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

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 numpy 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

[johnyf]

Closing to open a pull request into branch dev, instead of branch master. Retargeting the merge seems to be possible with some github-fu, but a first attempt failed and so just going to use the ugly solution.

[johnyf]

Re-opened after it was decided that a dev branch will not be used.

[slivingston]

After the pull request tulip-control/tulip-control#87 is accepted, changes from it will be incorporated here so that tulip and polytope are using the same non-release version strings protocols.