Cache built Setup.hs

[mgsloan]

Currently, Setup.hs always gets interpreted via runhaskell. Since it's invoked multiple times, and often just with the default Setup.hs, it could sometimes make sense to instead compile it (which is the approach taken by cabal install).

This is particularly relevant for GHCJS support (#337), as my current implementation needs to build Setup.hs as there isn't a runhaskell equivalent for GHCJS. So, instead it rebuilds Setup.hs every time it's invoked, leading to compiles that are much slower than they need to be.

This is a bit tricky, though, as we'd need a good way to track when the cached build of Setup.hs is out of date. Cabal does this by checking the timestamp of the file vs the binary, but I think this neglects changes due to modules that Setup.hs depends on.

[snoyberg]

Let's move discussion to #803.

[mgsloan]

Note that GHCJS builds which involve a custom Setup.hs will still be rather slow (recomputing the JS for it for each cabal invocation). However, this does resolve the slowness for the common case.