Avoid loading hackage index cache for extra-deps which are already installed?

[mgsloan]

This may have some relation to #2070 - the ability to ensure that we are always using the same cabal file.

As discussed here, it extra-deps cause the hackage cache to get loaded, as we need to get their cabal description. I haven't thought through all the details, but this doesn't seem necessary. The fix may be complicated, though:

There are two spots that need the cabal file:

stack/src/Stack/Build/ConstructPlan.hs

Line 286 in dd98fbc

p <- liftIO $ loadPackage ctx name version flags

stack/src/Stack/Build/ConstructPlan.hs

Line 320 in dd98fbc

package <- liftIO $ loadPackage ctx name version flags

In the case that we already have this package installed, there should be enough info in the package db, potentially even in ghc-pkg queries stack already made, to not need to load the cache.

We're going to be swapping out binary with faster serialization soon, so it may be that soon there won't be as much motivation for doing something sophisticated to avoid this 0.3s load time.

[snoyberg]

This is no longer relevant with Pantry, which stores these files in a quickly accessible SQLite database.