Rewrite Cabal in Shake

The Cabal build system today is very bad at avoiding redundant work. For example, when you ask it for a rebuild, it must always rerun the preprocessors... because it doesn't know any better. cabal new-build has a complicated change tracking mechanism built on top of the old-style Setup interface, because the Cabal library is simply not setup to handle it. Sharing a common, dependency graph creation abstraction, i.e., Shake, will help us solve these problems.

Here are the major architectural points that make sense to me at this point:

* The rewritten Shake-based Cabal would not even attempt to work with old custom setups, as it will probably be very hard to maintain library compatibility in the new world order. The new Cabal would initially just be used by cabal-install for Simple setups, and cabal-install would keep its old code to work with (now-legacy) Cabal for existing custom setups.

* Insofar that cabal-install uses linked Cabal for communicating with external Cabal (type definitions, marshalling, etc) the old Cabal will need to be kept around, so the new one should live in parallel. But parts of legacy Cabal not used by cabal-install can be scrapped as existing Custom setups would only link extent Cabal releases.

* Per-package custom build rules are still extremely useful. But since we are making a clean-break in the Cabal interface, and since this is one the oldest parts of the cabal-install/cabal ecosystem, this would be a good change to clean-slate rethink the interface. For example we can assume cabal-install/shake/etc would do all the solving so the packages should only work with the packages they are given. @Ericson2314 is a fan of packages defining their own Shake rules, or something else high-level and declarative that will integrate wonderfully with the new Cabal.

* Hadrian has some good ideas about how to design build systems for Haskell code (https://www.staff.ncl.ac.uk/andrey.mokhov/Hadrian.pdf); a rewrite of Cabal in Shake should take advantage of those ideas. (In particular, they have good ways of dealing with the tons and tons of flags we need to pass to the subprograms we call.)

* ToolCabal (https://github.com/TiborIntelSoft/ToolCabal) did this already. There are probably lessons to be learned from that code base.

* Although Shake-ifying Setup scripts would not directly improve parallelism, it could potentially hook into a Shake library for building Haskell modules which IS parallel (this might be the driver program described in #976), and then the parallelism would propagate to the entire build. Good!

* (More here)

CC @Ericson2314