select() on the Python mode should only see "PY2" or "PY3"

[brandjon]

Currently the configuration value corresponding to --force_python can never transition from null to PY2, due to a quirk in how the transition logic is implemented. (Basically, it sees that PY2 is the default value when null is specified, and decides that keeping it null is good enough.) This means that the same target never appears in both the PY2 and null configurations within the same build.

This would have changed in my fix for #1446. As it turns out, once you start to have targets built in both modes, you can get action conflicts because the build results are slightly different, even though both modes mean "use the Python 2 interpreter". This is because transitive dependencies can behave differently in null mode than in PY2 mode, for instance when you have a select() on "force_python".

The most straightforward immediate solution is to use a separate output path root for PY2 mode, like we already do with "-py3". This would have performance implications in that there'd now be three different ways you could redundantly rebuild the same targets, instead of just two.

A better solution is likely to eliminate null as a valid value for this mode entirely...

[brandjon]

Action conflicts will no longer be possible (at least, not via this mechanism) under the new model; see #6583.

[brandjon]

754dddc added a new select()-able Starlark-defined flag, @bazel_tools//tools/python:python_version. All code that selects on "force_python" should switch to this instead, in order to avoid action conflicts. Under --experimental_better_python_version_mixing, selecting on "force_python" will be disallowed.

[brandjon]

--incompatible_remove_old_python_version_api is flipped in Bazel 0.25, so it is no longer possible to select() on "force_python".