please_pex and test framework targets are mutually dependent #265

A long-running frustration is that several of the plugin's build definitions and the please_pex tool are mutually dependent. The clearest example of this is when trying to build the plugin using the please_pex build target as the plugin's pex tool, rather than a pre-built binary:

$ plz test -o "plugin.python.pextool://tools/please_pex"
Build stopped after 6.27s. 1 target failed:
    //third_party/python:behave
Dependency cycle found:
//third_party/python:behave
 -> //third_party/python:_behave#behave_bin
 -> //third_party/python:_behave#behave_bin_pex
 -> //tools/please_pex:please_pex
 -> //third_party/python:behave
Sorry, but you'll have to refactor your build files to avoid this cycle

The problem is that //tools/please_pex (which concatenates the various built-in test runners with the please_pex binary) depends on various third-party test runner (and other) modules defined in //third_party/python as python_wheels, which themselves require please_pex in order to be built as .pex files.

This circular dependency prevents changes from being made simultaneously to please_pex and the build definitions - instead a complex dance is required in which please_pex's old behaviour is retained by default but the new behaviour is available via command line options and/or feature flags, then a new please_pex version must be released which can be consumed in binary form by the rest of the repo via //tools:please_pex, then the build definitions must be cut over to use please_pex's new behaviour; only then can the old behaviour be removed from please_pex. Certain non-trivial changes (such as changes to the .pex format itself) actually might not even be possible to implement at all because of this.