Move `base` implementation to `ghc-internal`

This is the first step of CLC Proposal #209, which requires moving the IO manager into ghc-internal such that evtPeerClosed et al. can be exposed via ghc-experimental.

Of course, moving the event manager requires moving a significant fraction of base. Naturally, we would like to avoid moving all of base into ghc-internal, turning it into a mere set of module re-exports. However, this is a non-trivial undertaking for a variety of reasons:

• base contains numerous known-key and wired-in things, requiring corresponding changes in the compiler
• base contains a significant amount of C code and corresponding autoconf logic, which is very fragile and difficult to break apart
• base has numerous import cycles, which are currently dealt with via carefully balanced hs-boot files
• We must not break existing users

To accomplish this migration, I tried the following approaches:

• [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental migration of modules into ghc-internal: this knot is simply too intertwined to be easily pulled apart, especially given the rather tricky import cycles that it contains

• [Move-Core]: Moving the "core" connected component of base (roughly 150 modules) into ghc-internal. While the Haskell side of this seems tractable, the C dependencies are very subtle to break apart.

• [Move-Incrementally]:

  1. Move all of base into ghc-internal
  2. Examine the module structure and begin moving obvious modules (e.g. leaves of the import graph) back into base
  3. Examine the modules remaining in ghc-internal, refactor as necessary to facilitate further moves
  4. Go to (2) iterate until the cost/benefit of further moves is insufficient to justify continuing
  5. Rename the modules moved into ghc-internal to ensure that they don't overlap with those in base
  6. For each module moved into ghc-internal, add a shim module to base with the declarations which should be exposed and any requisite Haddocks (thus guaranteeing that base will be insulated from changes in the export lists of modules in ghc-internal

Here I am using the [Move-Incrementally] approach, which is empirically the least painful of the unpleasant options above.

For prototyping purposes, I am currently using reexported-modules to expose ghc-internals's modules from base. However, as noted above, this will be addressed properly in step (6) which will come next.