Filter out incompatible package versions from the global DB and specify exact dependencies to configure

[DanBurton]

See: #120 (comment)

The basic idea is that his global database has text-1.2.0.4, and some other things in the global database built against that, while his snapshot database has text-1.2.1.1.

src/Text/XmlHtml/TextParser.hs:74:48:
    Couldn't match expected type ‘text-1.2.0.4:Data.Text.Internal.Text’
                with actual type ‘Text’
    NB: ‘text-1.2.0.4:Data.Text.Internal.Text’
          is defined in ‘Data.Text.Internal’ in package ‘text-1.2.0.4’
        ‘Text’ is defined in ‘Data.Text.Internal’ in package ‘text-1.2.1.1’
    In the third argument of ‘P.parse’, namely ‘t’
    In the second argument of ‘inLeft’, namely ‘(P.parse p src t)’

[snoyberg]

This should dovetail with #124 nicely. We'll need to check the dependencies of all packages in the global database and, if any of them are not our selected versions, consider that package not installed.

[chrisdone]

So specify every package with -package when configuring, and when running ghci/ghc etc.

[chrisdone]

So in GhcPkg's getPackageVersionMap (or under a different name), we should exclude package-version identifiers which:

1. Are not listed in the snapshot (so text-1.2.3 is listed in the snapshot, then text-1.4.2 is excluded).
2. Depend on the above offending packages (so attoparsec-1.2.3 which is listed in the snapshot, but depending on text-1.4.2, will also be excluded).
3. Do not have profiling support.

Then in Build any place requiring package configuration, such as configure, running GHCi, runghc, etc. we should:

1. Specify our package databases in the order of global, snapshot, local (this will prefer packages from the latter ones first, which helps in the case of exact version matches but lacking profiling in the global case).
2. Specify the exact version of every package as -package foo-1.2.3, probably with -hide-all-packages at the beginning, to be completely precise.

With this in place, #124 will be solved automatically.

[chrisdone]

@snoyberg Are we good with this one?