Option to copy source files before build

## Desired workflow

I often encounter the circumstance where I want to do the following:

1) Make a change
2) Make another change while waiting on feedback from the build started in (1)
3) Not have these changes affect the build started in (1)
4) Start a build with the new changes, such that it does not conflict with the old build.

A workflow like this is feasible with multiple git repos, but that feels quite clumsy.

`ghc` loads all of the modules at the beginning of compilation, so once that's started it's no big deal. However, if stack needs to rebuild a bunch of deps, it will take a while before it reaches that point.
## Idea for a solution
- User runs something like `stack build --isolated` (not sure what to call the flag, `--copy` is taken)
- Create a new project root directory, and copy all of the relevant source files, taking into account dependency info gleaned from prior builds (TH qAddDependentFile, etc).

The ideal implementation would probably look something like a union file system, where we'd keep around the old files and the user's changes would just be new files shadowing the old. Copying should be quick for many projects, though. After all, what we're concerned about here is developer time.
## Incremental isolated builds?

The only way I can think of to have incrementality for these builds is for them to keep around their source files and build artifacts. So, whenever you run `stack build --isolated`, it'd pick one of these dirs and use it. This allows us to sometimes take advantage of incrementality. I think this'd also mean that the code to copy the source would need to detect when the content is identical and avoid `touch`ing the destination file.

See https://github.com/commercialhaskell/stack/issues/1634 for discussion of the design space around having multiple sets of dist dirs. Unfortunately, it does not seem to currently be possible to support both concurrent builds and incremental re-use of build results.
## Issue: source file paths

File paths will refer to the new locations. For opening files in their text editor, this isn't really what the user wants. On the other hand, if it uses the new location, the source location info will be accurate (whereas with the working copy files, things could have moved).