Motivation: avoid unnecessary recompiles. I held off on commenting on this until the new Cabal version with this support was announced, but given that it may be a while before that support filters down for everyone to be able to use it, I don't want to hold off any longer. Pinging @wolftune and @3noch from #771, and @borsboom and @chrisdone for general feedback.

Here's my idea:

• Inside ~/.stack, we have a package database for all libraries ever built with that version of GHC, Cabal version, etc. In other words: namespaced in the normal way we namespace these things.
• In order to work around Cabal limitations: when we configure with Cabal, we give it a temporary package database so it registers there and does not have an opportunity to unregister other packages in the mega-database. We then manually copy that registered package info into the mega-database.
• Instead of having a snapshot database in ~/.stack, the snapshot database moves into the project .stack-work directory. However, instead of containing the libraries themselves, it just contains a copy of the register files from the ~/.stack mega-database.
• We ensure that this database contains only the packages used by our project, including packages from the global database. That way: stack ghci and friends just include that database and the local database, and don't need to worry about conflicting packages.

Concerns:

• There's no intelligent story any more for deleting just one snapshot, you'd really have to wipe out all of ~/.stack. However, given how much less storage and recompiling will be needed, I think that's a worthwhile tradeoff.
• There's some tricky business around executables. We may end up needing to recompile executables more often if we can't figure out something smarter.