----------------
What:

There are two splits.

The first spit is:

 - `Language.Haskell.Syntax.Extension`
 - `GHC.Hs.Extension`

where the former now just contains helpers like `NoExtCon` and all the
families, and the latter is everything having to do with `GhcPass`.

The second split is:

 - `Language.Haskell.Syntax.<mod>`
 - `GHC.Hs.<mod>`

Where the former contains all the data definitions, and the few helpers
that don't use `GhcPass`, and the latter contains everything else. The
second modules also reexport the former.

----------------
Why:

See the issue for more details, but in short answer is we're trying to
grasp at the modularity TTG is supposed to offer, after a long time of
mainly just getting the safety benefits of more complete pattern
matching on the AST.

Now, we have an AST datatype which, without `GhcPass` is decently
stripped of GHC-specific concerns. Whereas before, not was it
GHC-specific, it was aware of all the GHC phases despite the
parameterization, with the instances and parametric data structure
side-by-side.

For what it's worth there are also some smaller, imminent benefits:

- The latter change also splits a strongly connected component in two,
  since none of the `Language.Haskell.Syntax.*` modules import the older
  ones.

- A few TTG violations (Using GhcPass directly in the AST) in `Expr` are
  now more explicitly accounted for with new type families to provide the
  necessary indirection.

-----------------
Future work:

- I don't see why all the type families should live in
  `Language.Haskell.Syntax.Extension`. That seems anti-modular for
  little benefit. All the ones used just once can be moved next to the
  AST type they serve as an extension point for.

- Decide what to do with the `Outputable` instances. Some of these are
  no orphans because they referred to `GhcPass`, and had to be moved. I
  think the types could be generalized so they don't refer to `GhcPass`
  and therefore can be moved back, but having gotten flak for increasing
  the size and complexity types when generalizing before, I did *not*
  want to do this.

- We should triage the remaining contents of `GHC.Hs.<mod>`. The
  renaming helpers are somewhat odd for needing `GhcPass`. We might
  consider if they are a) in fact only needed by one phase b) can be
  generalized to be non-GhcPass-specific (e.g. take a callback rather
  than GADT-match with `IsPass`) and then they can live in
  `Language.Haskell.Syntax.<mod>`.

For more details, see
https://gitlab.haskell.org/ghc/ghc/-/wikis/implementing-trees-that-grow

Bumps Haddock submodule