split ghci modules off into their own package

[igloo]

ghci code should be split into bits that are always compiled (and always work), and modules that are in a separate ghci package. The current situation means that clients of the GHC API cannot specify whether or not they need the ghci modules (or other code inside GHCI ifdefs), and means that clients may accidentally end up using ghci-only interfaces without realising it. This is not just hypothetical: haddock has grown a dependency on ghci code: #3558.

[simonmar]

I don't think we can split off a separate ghci package, because it would be mutually recursive with the ghc package. The main reason for the GHCI #ifdef is that we can only use GHCi in stage 2 when the libraries we dynamically load are the same as the ones that GHC itself is linked with, so that data representations etc. are compatible. We never ship a ghc package without GHCi support, so clients don't need to worry about this.

Now, it's possible we could pull enough code out from inside GHCI to fix the Haddock issue described above, and that's not a bad thing. But I don't think this is an issue that affects any other clients.