…ildroot (#7522)

### Problem

Running the below command results in a `clean-all` being run before the integration test:
```
> ./pants2 test tests/python/pants_test/backend/python/tasks:: -- -s -k test_platform_defaults_to_config
...
10:32:53 00:06     [pytest]
                   Invalidated 21 targets.
                   scrubbed PYTHONPATH=/Users/dmcclanahan/tools/pants/src/python: from py.test environment
10:32:53 00:06       [run]
                     ============== test session starts ===============
                     platform darwin -- Python 2.7.10, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
                     rootdir: /Users/dmcclanahan/tools/pants/.pants.d, inifile: /Users/dmcclanahan/tools/pants/.pants.d/test/pytest-prep/CPython-2.7.10/718d17b455ce5917535680e933c8a655f6334861/pytest.ini
                     plugins: timeout-1.2.1, cov-2.4.0
                     collected 142 items / 141 deselected

                     tests/python/pants_test/backend/python/tasks/test_python_binary_integration.py .python-interpreter-constraints not found in the buildroot.
                     Forcing an initial clean-all.
                     Different interpreter constraints were set than were used in the previous Pants run.
                     Clearing the cache and preparing a Python environment with these interpreter constraints:
                     ['CPython>=2.7,<3','CPython>=3.6,<4']
...
```
This is an artifact of the changes for #7151, which tries to be safe and clean-all if the `.python-interpreter-constraints` file doesn't exist to ensure subprocesses are invoked with the right python version. But we don't need to do this for integration tests, since they're invoked in a new buildroot.

### Solution

- Add `ONLY_USING_SINGLE_PYTHON_VERSION=true` to the env in all integration tests.

### Result

Pants will no longer run a clean-all before integration tests in a new buildroot.

…ave changed (#7586)

### Problem
Currently we only check for changes to the file's `compatibility` entry in its `BUILD` file, but really we should be also checking global constraints.

As it stands now, changing `--python-setup-interpreter-constraints` will have no impact until running `./pants clean-all`, which is not meant to be.

This closes #7510.

### Solution
Use `PythonSetup`'s `compatibility_or_constraints` in the fingerprint strategy, which first checks if the targets have `compatibility` marked in their BUILD entries, and then falls back to the global interpreter constraints.

#### Alternative solution: invalidate upon subsystem changes
Alternatively, we could add `self.fingerprint` to our file naming scheme, so that _any_ invalidation to `PythonSetup` or to `PythonInterpreterCache` would also invalidate this task. See d35e80c#diff-3d23a0b5af958441c095d5acd551ac16R101 for this implementation.

We did not go down this route because it would result in more invalidation than necessary. This task is only ever impacted by changes to `--python-setup-interpreter-constraints` and `compatibility` entries.

#### Also revert auto clean-all
#7151 and #7522 were workarounds to this underlying issue.

### Result
Calling `PANTS_PYTHON_SETUP_INTERPRETER_CONSTRAINTS="['CPython==3.6.*']" ./pants test --cache-ignore tests/python/pants_test/util:strutil` the first time will cause an invalidation, then the interpreter selection task will not run upon subsequent invocations.

Running `PANTS_PYTHON_SETUP_INTERPRETER_CONSTRAINTS="['CPython==2.7.*']" ./pants test --cache-ignore tests/python/pants_test/util:strutil` right after will properly cause an invalidation and result in Python 2.7 being used for the tests.