Inplace build profiles, to avoid clobbering old build products when you change some settings

Here are a number of situations, all with something in common:
1. If you `cabal new-build`, and then `cabal new-repl --ghc-option=-fobject-code`, the REPL dumping out object code will clobber the originally built code from `new-build`
2. If you `cabal new-build --disable-optimization`, and then decide you do want to build with optimization, changing the flag is insufficient; you have to blow away the old build products. (And there is no way to maintain the unoptimized and optimized build trees simultaneously)
3. If you decide you want to enable some debugging Cabal flag, and then disable it later

In all of these situations, there is some parameter which Cabal knows about, but then when it comes to the actual build products Cabal stuffs them all in the same directory; thus, when one of these flags changes, Cabal blows away the old build products (without considering the possibility they might be useful for later.)

Here's how I think we should solve this: instead of always assigning inplace packages an inplace package ID, we should compute a Nix-style hash for it. We can symlink the inplace directory to the most recently computed hash for a package. The Nix hash should not be complete (e.g. it shouldn't include any sort of hash of the source code); it should just track parameters which (1) the user is likely to want to build their project with under both permutations, and (2) would require most of the package to be rebuilt.