Restructure the ruleset surface area to allow for more purpose-oriented binaries

[arrdem]

Discussed at some length with Jimmy -- Today we have py_pex_binary which is good and serves a narrow purpose and the new py_venv_binary which also serves a clear purpose. But users are broadly under the misapprehension that what is today called py_binary (see #587) is generally suitable as is what rules_python calls py_binary. The existing "binaries" such as Pex and the reference runfiles binary all make specific and consequently specifically inappropriate tradeoffs. Rather than presenting one as "the" binary implementation users should be forced to make a suitable to task decision.

Thinking out loud

The reality is that Python isn't designed for "binaries", it's more consistent with the world outside of Bazel think about venvs and entrypoints. It likely makes sense to reconsider the `PyInfo` structure as consisting of three parts; files, import prefixes and a list of entrypoints (think `console_scripts`). A `py_library` happens to specify no scripts. A `py_binary` happens to specify a script. Stitching multiple binaries with internally consistent deps together into a single venv should be a clearly supportable operation. Similarly choosing an _entrypoint_ out of a venv to be hit as part of a _closed_ artifact such as a sci-e, pex or other "binary" should be a distinct operation.

The need for such a thing becomes obvious when considering optimized Docker artifacts potentially containing several "binaries" (entrypoints). It isn't obvious to users that the "correct" way to do this under Bazel should be to create a real composite rule which forces the runfiles from several subsidiary binaries to become merged into a unified container-like artifact.