C++ action conflicts when using new Python version transition semantics

[brandjon]

When --incompatible_allow_python_version_transitions is enabled, it is possible to see action conflicts like the following:

# pkg/BUILD

cc_binary(
    name = "cc",
    srcs = ["cc.cc"],
)

py_binary(
    name = "py2",
    srcs = ["py2.py"],
    data = [":cc"],
    python_version = "PY2",
)

py_binary(
    name = "py3",
    srcs = ["py3.py"],
    data = [":py2"],
    python_version = "PY3",
)

bazel build --nobuild :cc :py3 --incompatible_remove_old_python_version_api --incompatible_allow_python_version_transitions

ERROR: file 'pkg/_objs/cc/cc.pic.o' is generated by these conflicting actions:
Label: //pkg:cc
RuleClass: cc_binary rule
Configuration: 83cd5d9d7f630a049607dfd50cf4dde5, 8828d01484e6d3655aa5a2fb816f8caf
Mnemonic: CppCompile
Action key: 1087c9369f354d7ff811a0fac206e6c6
Progress message: Compiling pkg/cc.cc
PrimaryInput: File:[/usr/local/google/home/brandjon/src/test[source]]pkg/cc.cc
PrimaryOutput: File:[[<execution_root>]bazel-out/k8-fastbuild/bin]pkg/_objs/cc/cc.pic.o
Primary outputs are different: 905832647, 1461097947
Owner information: //pkg:cc BuildConfigurationValue.Key[83cd5d9d7f630a049607dfd50cf4dde5] false, //pkg:cc BuildConfigurationValue.Key[8828d01484e6d3655aa5a2fb816f8caf] false
MandatoryInputs: are equal
Outputs: Attempted action contains artifacts not in previous action (first 5): 
	pkg/_objs/cc/cc.pic.o
	pkg/_objs/cc/cc.pic.d
Previous action contains artifacts not in attempted action (first 5): 
	pkg/_objs/cc/cc.pic.o
	pkg/_objs/cc/cc.pic.d
ERROR: com.google.devtools.build.lib.actions.MutableActionGraph$ActionConflictException: for pkg/_objs/cc/cc.pic.o, previous action: action 'Compiling pkg/cc.cc', attempted action: action 'Compiling pkg/cc.cc'
INFO: Elapsed time: 1.415s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (15 packages loaded, 202 targets configured)

This was supposed to be fixed in 09c6b7a, but it turns out more work is needed to ensure that we don't produce separate configurations for when --python_version is set to the default value explicitly, versus when it is set ot the default value by, well, default. We have a fix in mind and hopefully should have it in place for Bazel 0.25, when we intend to flip the flag.

[brandjon]

I have a prototype fix and just need to polish it and add some javadoc / tests.