Effects: 

Some cleanup and tidying to prepare for adding the HProp. 

Lots of crosscutting changes, so want to merge sooner rather than later.
@ranjitjhala I agree with your argument that big functions should generally be avoided, but I'm not convinced that this is a good solution. I think it's better to have a function that constructs a whole `GhcSpec` rather than 5 functions that construct (somewhat arbitrary) parts of a `GhcSpec`. The `GhcSpec` type has a ton of fields, so there's *necessarily* going to be a lot of logic involved in constructing one.

That being said, the existing `makeGhcSpec'` could certainly be cleaned up. I think a healthy compromise between avoiding large functions and arbitrary division of logic would be something like the following:

```haskell
makeGhcSpec args
  = do (tySigs, asmSigs) <- makeSigs
       exports <- makeExports
       invariants <- makeInvariants
       ...
       return $ SP { .. }
```

i.e. pretty similar to the current structure, but with a hard restriction that we split out generation of each field into a separate function (unless it's natural to group construction of a couple fields, like perhaps `tySigs` and `asmSigs`). So, for each field of the `GhcSpec` we'd have a statement `foo <- makeFoo makeFooArgs -- capturing dependencies between fields`.

With this pattern we should be able to cleanly separate the logic for constructing individual fields of the `GhcSpec`, while retaining a function that provided a holistic view of the entire process.