allow adding to pythonpath via pant.ini

Looks like this used to work, based on a comment (recently removed) that said:
```
"""
  To add additional paths to sys.path, add a block to the config similar to the following:
  roots: ['src/python/pants_internal/test/',]
"""
```
The provides an alternative to `PYTOHNPATH=custom/pants/stuff ./pants goal ...` when using
an in-repo custom register.py.

Note that this is unrelated to plugins distributed as dists and installed in the (virtual)env
from which pants is run / loaded with pkg_resources, or source backends packaged into a custom
dist or pex of pants.

This change restores that functionality, though it is now called `python-path` for clarity and
lives in the `[backends]` config section.

Bugs closed: 856

Reviewed at https://rbcommons.com/s/twitter/r/1457/
Enable caching in the Travis CI build.

The specs here:
  http://docs.travis-ci.com/user/caching

This turns on caching for ~/.pants.d, ~/.ivy2
and the current pants requirements bootstraped in
build-support.  To make virtualenv caching work, updates
the virtualenv bootstrap script to use a stable directory name
across virtualenv versions.

Testing Done:
CI went green here: https://travis-ci.org/pantsbuild/pants/builds/44760074

Bugs closed: 887

Reviewed at https://rbcommons.com/s/twitter/r/1537/
Improve CI caching.

Add an option to skip pants bootstrap pre-clean
allowing cached build-support/pants_dev_deps.venv
to survive and be utilized.

I missed this cleaning going on in ci.sh when 1st enabling caching in https://rbcommons.com/s/twitter/r/1537/
This change actually uses the build-support/pants_dev_deps.venv now to avoid pip installing pants deps unless they change as evidenced by logs.

Testing Done:
CI went green here: https://travis-ci.org/pantsbuild/pants/builds/44795443

Bugs closed: 888

Reviewed at https://rbcommons.com/s/twitter/r/1538/
Refactor WhatChanged into base class, use LazySoruceMapper

Switch to using LazySourceMapper to map changed files to targets.
LazySourceMapper is designed to map sources to targets without
loading any more of the BUILD graph than is required, which is
ideal for a what-changed use-case.

Refactoring the what-changed calculation into base class should make
it easier to support other tasks that require the set of changed
targets (or files). The WhatChanged task itself is now just a small
stub on top of it.
Add changes-in-diffspec option to what-changed

Instead of looking at changes in the workspace relative to some parent ref/treeish, this
allows finding targets changed by some diffspec that is meaningful to the scm, eg a commit
SHA, a commit range, or other ref/ref-range.