Move to subprocess-based API

[jvkersch]

This came up in a number of issues and also in the experimental PR #30.

I am planning to move the library from a Cython-based implementation, in which a Python extension module is built that links directly against the Concorde library, to a subprocess-based implementation, where the library calls Concorde in a subprocess. I am normally more in favor of the first approach because it is more efficient and more easy to manage (everything runs in the same process, there is no need for serialization/deserialization, etc) but in this case the second approach has some clear advantages:

• While Concorde makes an API available, it is clear that the solver is principally meant to be called through the executable. This has lead in the past to a few cases where the tour computed by the Concorde executable was different from the tour computed with this package.
• The format to present a TSP instance and to return a computed tour are fairly standardized, and are easily supported in code (using e.g. the tsplib95 library). Having these interfaces exposes an "escape hatch" for debugging or to access a feature that is not exposed through the code: simply take the TSP specification and run the Concorde solver manually.
• The build process simplifies a bit, as there are compiled binaries available for e.g. Windows.
• Other solvers, like LKH, can likely be supported with the same API.

At the time of writing some parts of the subprocess API are already present in main but they have not been documented. The plan for moving completely to the subprocess API is as follows:

• Maintain a long-running branch for bugfixes to the Cython-based API (version 0.1 of the code). I can see that we will want to at least fix Symbol not found: _CCtsp_solve_dat - Error after installing pyconcorde #22 on this branch.
• Document the subprocess API (Document the subprocess API #56)
• Provide wheels for the new API (Build wheels for subprocess API #57)
• Deprecate the Cython API and release the subprocess API as version 0.2 of the code.

This will be done in such a way so that the impact on existing users is minimal (while the new API is being added, the old API will remain functional, and after the new API has been formally released, the old API will remain available in maintenance mode on the 0.1.x branch). However, the new API will not be identical to the old API.