Support module thinning and renaming Cabal-side.

NB: unlike GHC, Cabal will still try to find a globally consistent choice for
all package names, i.e. this does *not* implement private dependencies.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Mmm, this is a bit irksome. After parsing, we mostly want just the dependency and thinining/renaming as seaprate things I think. I wonder if we can't have the external representation use one build-depends field, but have the internal representation use two independent record fields.

Then we'd only need the `FullDependeny` (need a better name!) in a few places in the parser / pretty printer.