Refactor MungedPackageId and PackageIndex.
This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb to handle component configuring correctly. It probably is a good step towards pkg:lib style dependencies. The big ideas: * There's a new AnnotatedId type, which is any identifier (like ComponentId), but also with a PackageId and ComponentName. It's a bit like ConfiguredId, but ConfiguredId is specialized for ComponentId. There's a conversion function annotatedIdToConfiguredId. * We adopt a totally new strategy for handling MungedPackageId in InstalledPackageInfo. Rather than store the munged package identifier in IPI, we NEVER store it, instead computing it from the package name and library name (which are stored.) There is now code to PARSE a munged package name into these two components, so that when we read 'name' we get the correct info. The resulting code is splendidly clear. * Some places where we took a ComponentName (notably computeCompatPackageName) we now take 'Maybe UnqualComponentName'. This is more accurate, because compatibility package names are only computed for libraries, not other components. Some code in Distribution.Backpack.ReadyComponent is partial now, but the invariants should hold up. * A number of places where MungedId was applied, I undid them. Most notable are macro generation (that should be PACKAGES, not components) and mkLegacyUnitId (since REALLY old style unit identifiers, we won't support internal libraries anyway.) * Many functions in PackageIndex are monomorphized to InstalledPackageInfo. Fortunately cabal-install's usage still works. * Distribution/Client/SolverPlanIndex.hs, not used by anyone, got the axe. * Dependency solving has a hack to solve the problem of how to interpret installed internal libraries in the package database. The basic idea is that, although in most cases where we used a MungedId, we say it explicitly, in the SOLVER, we munge *installed package names* only, and keep the type PackageName. It's a hack, but the alternative is to write a lot more code. Note that is MORALLY PN is indeed a PackageName, since we really are solving for honest to goodness packages, not components! See Note [Index conversion with internal libraries] for more details. * ConfiguredId now records the ComponentName. This is quite important, because we need to use it to figure out how we are going to phrase --dependency. In fact, it is a miracle that this worked at all (and it only worked because of a very skeevy update to the PackageId in the creation of ConfiguredComponent). Irritatingly, this must be a Maybe ComponentName, because a ConfiguredId MIGHT refer to a setup component. Very distressing. Signed-off-by: Edward Z. Yang <firstname.lastname@example.org>