Here are the main changes:

Distribution/Client/InstallPlan.hs
    New utility function 'fromSolverInstallPlanWithProgress'
    which is a monadic version of 'fromSolverInstallPlan'.
    This is because, with Backpack, the conversion from
    'SolverInstallPlan' to 'InstallPlan' can fail/log.

Distribution/Client/ProjectPlanning/Types.hs
    OK. A bunch of new information we need to track.

    New fields in 'ElaboratedConfiguredPackage':
        elabInstantiatedWith :: ModuleSubst (for --instantiated-with)
        elabLinkedInstantiatedWith :: IndefModuleSubst (intermediate)
        elabModuleShape :: ModuleShape (for mix-in linking)

    Here is how all the dependency functions relate to
    one another:

        elabOrderDependencies :: [UnitId]
            Used for nodeNeighbors, this just specifies what needs
            to be built before we build this module.  These refer
            either to fully instantiated unit ids (hashed unit id)
            or uninstantiated unit ids (effectively component id)
            but never a partially instantiated unit id, since we
            never have an install item in our plan for a partially
            instantiated package.

            These dependencies are factored into two parts:
                elabOrderLibDependencies
                elabOrderExeDependencies
            which soley are used to determine if we need to enable
            executables/libraries of a package we are building
            (this isn't new)

        elabLibDependencies :: [ComponentId]
            These are the things we pass to Setup using the --dependency
            flag; so they are JUST ComponentId, not a full on UnitId.
            The mix-in linking process in Setup will reconstruct the
            necessary UnitId.

        elabExeDependencies :: [ComponentId]
            These are the things that we must add to the PATH to run.
            At the moment, this coincides with elabOrderExeDependencies.

    For components, there is also:

        compLinkedLibDependencies :: [IndefUnitId],
            The partially instantiated unit ids that GHC would be
            invoked with, if we were invoking it directly.
            This is used when we subsequently instantiate components.

        compNonSetupDependencies :: [UnitId]
            Non-setup, ORDER dependencies; i.e., everything that has
            to be built before us that is not a setup script.

Distribution/Client/ProjectPlanning.hs
    The workhorse.

    Essentially, we redo all of the steps from
    Distribution.Backpack.Configure, but in the context of planning an
    entire install plan.  The conversion from SolverInstallPlan
    to InstallPlan is responsible for mix-in linking
    (inside elaborateSolverToComponents); afterwards,
    instantiateInstallPlan is responsible for filling in
    the missing, instantiated packages which we need to compile.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>