Rationalise GhcMode, HscTarget and GhcLink

Rationalise GhcMode, HscTarget and GhcLink

This patch cleans up the GHC API, and adds some functionality: we can
now compile to object code inside GHCi.

Previously we had:

  data GhcMode
    = BatchCompile
    | Interactive
    | OneShot
    | JustTypecheck
    | MkDepend

  data HscTarget
    = HscC
    | HscAsm
    | HscJava
    | HscInterpreted
    | HscNothing

There was redundancy here; if GhcMode is Interactive, then only
HscInterpreted makes sense, and JustTypecheck required HscNothing.
Now we have:

  data GhcMode
    = CompManager       -- ^ --make, GHCi, etc.
    | OneShot           -- ^ ghc -c Foo.hs
    | MkDepend          -- ^ ghc -M, see Finder for why we need this

and HscTarget remains as before.

Previously GhcLink looked like this:

  data GhcLink = NoLink | StaticLink

Now we have:

  data GhcLink = NoLink | LinkBinary | LinkInMemory

The idea being that you can have an HscTarget of HscAsm (for example)
and still link in memory.

There are two new flags:

  -fobject-code selects object code as the target (selects
                either -fasm or -fvia-C, whichever is the default)
                This can be usd with ':set' in GHCi, or on the command line.

  -fbyte-code   sets byte-code as the target.  Only works in GHCi.
                One day maybe this could save the byte code in a file
                when used outside GHCi.

  (names chosen for consistency with -fno-code).

Changes to the GHC API: newSession no longer takes the GhcMode
argument.  The GhcMode defaults to CompManager, which is usually what
you want.  To do JustTypecheck now, just set hscTarget to HscNothing.