Reduce AST & parser dependencies

In !5719 (closed), the number of parser dependencies edged up a bit, to the dissatisfaction of @shayne-fletcher-da. See https://blog.shaynefletcher.org/2020/10/ghc-lib-parser-module-count.html for more info. This ticket is about how to get the number of modules transitively depended on by the parser down.

I actually just tried to do it, but it's not so easy. Here is what I learned:

• SOURCE imports matter, because a SOURCE import still has to be in the same package as its importing module. Thus, if the parser depends on some low-level module that SOURCE-imports a high-level one, we're in for trouble.
• A key problem is that the parser transitively depends on GHC.Driver.Env, which brings in GHC.Driver.Hooks and transitively odd things like GHC.Cmm. No no no.
• It's hard to figure out exactly where this link happens, absent a visualization tool (which I did not try to set up).
• I found at least one way in, via GHC.Hs.Expr, which SOURCE-imports GHC.Tc.Types, which imports GHC.Driver.Env. So a good next step would be to not do this.
• Of course, the parser has to depend on its AST, exported from GHC.Hs.Expr. But does it? It really only needs the GhcPs variant of the AST. So I propose breaking GHC.Hs.Expr into GHC.Hs.Expr.Parser, GHC.Hs.Expr.Rename, and GHC.Hs.Expr.Tc, each of which includes the definitions needed for its pass of the compiler. It seems likely we'd be able to get GHC.Hs.Expr.Parser not to depend on GHC.Tc.Types, and thus perhaps not on GHC.Driver.Env. I have not tried this, at all, because it would be fairly major surgery, and it would make looking up type instances for e.g. XHsPar harder. This seems like a promising way forward, however.

I'm moving on from this challenge now. This ticket is merely to serve as a small brain dump of what I accomplished. I pushed some (working) code to the wip/lower-parser-deps branch, which anyone is free to take over. That commit successfully drops the dependency on GHC.Core.Lint, and breaks up GHC.Cmm.Expr in an attempt to kill the dependency on GHC.Cmm. That last effort succeeded at breaking up GHC.Cmm.Expr, but did not actually lose any dependency. (It actually picked up two new dependencies, because I created two new modules.) Perhaps picking up this branch is helpful, or perhaps not. I leave it to the next person to decide.