Don't use .par files for piptool/whltool

[brandjon]

piptool and whltool are implicit dependencies of the pip_import and whl_library rules, yet they themselves are defined in terms of requirement() declarations. This circular dependency is currently resolved by checking in prebuilt .par files for these tools, regenerated by running update_tools.sh. This has drawbacks:

1. It makes the build process more brittle and harder to understand.

2. For security, the checked in par files must only be updated by a trusted person.

See also my recap here, a brittleness breakage here, and an uncompleted PR to migrate away from checked-in .par files here.

[brandjon]

To clarify, I think there's three separate issues here:

1. The tools are precompiled binaries, which means they can only be updated by trusted developers.

2. The tools are built using rules_python itself, so we have to follow a bootstrapping process when updating them.

3. The tools are par files, which means their build process depends on google/subpar.

For 1, we need these tools to be directly executable because Bazel cannot build its own tools during WORKSPACE evaluation. There's two ways to have an executable Python program: build an artifact (e.g. with Bazel), or else directly execute Python source code without a build step. We currently do the former, but a change like PR #81 does the latter.

For 2, the tools themselves have PyPI dependencies (which happen to be pip, setuptools, and wheel). The current approach of building the tools with rules_python itself provides a convenient way to obtain these dependencies without vendoring, at the cost of added build complexity. #81 switches to vendoring.

For 3, it's not clear to me that the use of par files is necessary, even if we don't vendor. We could explore switching to py_binary independently of eliminating the circular dependency of rules_python on itself. This would allow us to eliminate subpar from our user-facing dependencies.

[alexeagle]

rules_python 0.1.0 has been released which upstreams the rules_python_external repo. Please switch from pip_import to pip_install which doesn't have this issue.