[Ekapkgs] Refactor stdenv rep into mkPkgs and corepkgs

[jonringer]

Although I was hoping to have a small "nucleolus" of complexity separated away from larger package sets, it's still very awkward to have "some package management" in one repo, just to have overlays potentially affect the stdenv in another repo.

Instead:

• move all packaging concerns (stdenv and dependencies) move back into corepkgs
• repurpose current stdenv repo into a mkPkgs repo, which handles all of the logic around:
  • instantiating the pkgs package set(s) (E.g. pkgsMusl, pkgsCross)
  • release lib (E.g. hydra jobsets)

[blaggacao]

While this intuitively already sounds right, could give a couple more examples of instances of the "very awkardness" that the current model entails?

[jonringer]

Keeping libc or gcc up to date. May as well shove the packaging workflows into one "crucial" body of software. Having it split across many just leaves it more vulnerable to staleness.

Also, reducing the scope means that bumping it will be less often.