This will shortly be used in the package configuration step.

Distribution/Utils/Progress.hs
    A copy of the Progress monad from cabal-install solver, which we use
    to report failure and logging from otherwise pure code.

Distribution/Backpack/ModSubst.hs
    Defines a type class ModSubst for semantic objects that can have
    module substitutions defined over them.  Helps us define ModSubst
    functorially.

Distribution/Backpack/ModuleScope.hs
    A module scope represents the set of required and provided modules
    which are "in scope", i.e., available for import and mix-in linking.
    This is not a simple mapping from module name to module, as we're
    permitted to have conflicting definitions for a module name as long
    as we don't actually use it.  There's a comment which explains this
    more clearly in the file.  These are based off of 'IndefModule'
    because not all modules in scope are necessarily fully instantiated.

Distribution/Backpack/ModuleShape.hs
    A module shape describes the provisions and requirements of a
    library.  It's similar to a module scope, except that every
    export must be unambiguous; it too is based off of 'IndefModule'.

Distribution/Backpack/FullUnitId.hs
    An 'IndefUnitId' is not guaranteed to record a module substitution
    (it could be opaquely represented as a hash); a 'FullUnitId',
    however, IS guaranteed to do so.  Given, for example, an installed
    package database, we can map opaque 'UnitId' into their expanded
    representation.  This can be important to handle obscure unification
    problems when mix-in linking.

Distribution/Backpack/UnifyM.hs
    The unification monad, unifiable variants of Module/UnitId (with
    conversions to and from), and low-level unification operations on
    them.  Uses 'UnionFind' heavily.

    There is some commented out support for handling recursive
    unification.  At present there is no surface syntax for representing
    such situations.  (We would also need DFA minimization to
    canonicalize these regular trees.)

Distribution/Backpack/MixLink.hs
    The actual implementation of mix-in linking, on top of the
    unification monad 'UnifyM'.  The key function is 'mixLink',
    which takes two module scopes and links them together.

Distribution/Utils/LogProgress.hs
    The progress monad, specialized with LogMsg traces and Doc
    errors.  We provide a function to run such computations,
    outputting traces according to their 'Verbosity' and 'die'ing
    if there is an error.

Distribution/Backpack/ComponentsGraph.hs
    A small helper function for handling the source-level graph
    of components (so, just the relationship between stanzas
    in a Cabal file.)  This components graph will eventually get
    elaborated into a more complex graph with instantiations, etc.

Distribution/Backpack/Id.hs
    A helper module which now contains the functions for computing
    component identifiers and compatibility package keys.  This
    functionality used to live in Distribution.Simple.Configure
    but I split it out.  There are also adjustments to handle
    the new Backpack functionality.

Distribution/Backpack/ConfiguredComponent.hs
    A configured component is one for which we've resolved all
    source level dependencies (e.g., every entry in build-depends,
    we know the specific transitive versions of each thing
    we're going to use.)  That means we have a 'ComponentId' for
    this component.  This module also contains functions for
    creating a 'ConfiguredComponent' from a source 'Component'.

Distribution/Backpack/LinkedComponent.hs
    A linked component is one which we have done mix-in linking
    for, so we know its 'IndefUnitId' and its 'IndefUnitId'
dependencies.
    This module calls out to mix-in linking to actually do linking.
    The workhorse, in a sense!

Distribution/Backpack/ReadyComponent.hs
    This module implements the instantiation process, where we
    zip through all of the fully instantiated components, and
    recursively instantiate their dependencies, so that we
    get a separate linked component per thing we need to
    compile, and also finishes off any top-level indefinite
    components.  This gives us the final 'UnitId' for our
    units.

    This functionality is reimplemented in a different way in
    cabal-install; the assumptions are slightly different (in
    particular, in the library we can't assume we have access to all
    packages to build them; but in cabal-install we can assume it) so I
    didn't try to abstract over both implementations.

Distribution/Backpack/PreExistingComponent.hs
    This is a "interoperability" data type which identifies
    precisely the information from a 'LinkedComponent' that
    can be derived from an 'InstalledPackageInfo'.