Stop shuffling output files around so often

This commit is an architectural change inside of Cargo itself in the way that it
handles the output format of builds. Previously when a build start, all existing
directories and files would be renamed to `old-foo` folders. The build would
then `rename` all files back into the right location as they were seen as fresh
and needed for the build.

The benefit of a system such as this is a rock-solid guarantee that the build
tree contains exactly what it would if we were to start the build from a totally
clean directory each time. There are some downsides, however:

* In #800, it was discovered that this method has an unfortunate interaction
  with Docker. Docker apparently will mount many filesystems which `rename` will
  not work across.

* I have seen countless flaky failures on windows due to an attempt to remove a
  file that was still in use somehow. I've never been able to truly track down
  why these failures are happening, however.

The new system for managing output files is to build up a list of all known
files at the start of a build, whitelist any necessary files when the build is
being prepared, and then wipe out all unknown files right before the build
begins. This is not quite as close to the guarantee as the benefits reaped
before because on the second build all build files will still be in their final
output locations, they may just get updated as part of the build as well. This
seems like an acceptable compromise, however.

Closes #800
auto merge of #861 : alexcrichton/cargo/issue-800, r=brson

This commit is an architectural change inside of Cargo itself in the way that it
handles the output format of builds. Previously when a build start, all existing
directories and files would be renamed to `old-foo` folders. The build would
then `rename` all files back into the right location as they were seen as fresh
and needed for the build.

The benefit of a system such as this is a rock-solid guarantee that the build
tree contains exactly what it would if we were to start the build from a totally
clean directory each time. There are some downsides, however:

* In #800, it was discovered that this method has an unfortunate interaction
  with Docker. Docker apparently will mount many filesystems which `rename` will
  not work across.

* I have seen countless flaky failures on windows due to an attempt to remove a
  file that was still in use somehow. I've never been able to truly track down
  why these failures are happening, however.

The new system for managing output files is to build up a list of all known
files at the start of a build, whitelist any necessary files when the build is
being prepared, and then wipe out all unknown files right before the build
begins. This is not quite as close to the guarantee as the benefits reaped
before because on the second build all build files will still be in their final
output locations, they may just get updated as part of the build as well. This
seems like an acceptable compromise, however.

Closes #800