Paver (Part 1) -- Attempt 2

When I merged the Paver PR into master, Jenkins started failing in bizarre ways.  It turns out that:

1) When we run the test suite, we `pip install -e .` (here: https://github.com/edx/edx-platform/blob/master/requirements/edx/local.txt#L2)
2) This adds the path to the current repo directory into `sys.path`.
3) However, in Jenkins, there are multiple copies of the repository (for each job, and each sub-job in a multiconfig job).
4) Therefore, when we first use Python, `sys.path` may contain the path to another repo.
5) Because we run `paver` *before* re-running `pip install` on local requirements, the `pavelib/assets.py` in another copy of the repository was taking precedence over the local copy.
6) The other copy of `pavelib/assets.py` constructed a path to the wrong repository, where the prereqs cache indicated that `coffee` had already been installed (in "node_modules/.bin")
7) Since `coffee` had NOT, in fact, been installed in the current repository, coffescript compilation would fail.

Whew!

The right solution is probably to have Jenkins better isolate virtualenvs between jobs.  But that would be unacceptably slow, which is why we don't do it.

The solution I've adopted here is to insert the current working directory as the first item in `sys.path` before loading the pavement modules.  This ensures that Paver thinks it's in the right directory.

The only difference between this and the original PR is the sys.path manipulation in `pavement.py`, which includes a detailed comment.