Make package dependencies consistent with Cabal

Right now ghc-mod doesn't pay any special attention to which packages it exposes if multiple packages with the same name but different versions are available. While this is mostly fine as there can only be one version of every package in a sandbox anyways, and given that ghc-mod is a development tool this would be the most likely case, there are situations where a more sophisticated approach is needed. Notably while with a sandbox packages in the user database are not visible ones from the global database are still exposed.

Furthermore distributions like Debian install all packages installed through it's package manager into the global package database. From this I conclude that it is rather likely that two different version of the same package might be visible to ghc-mod even in a sandbox scenario. In this case ghc-mod might pick an out of date version of a package or, even worse, pick a package version that is incompatible with the version constraints in the cabal file which could lead to incorrect completions being generated or code that compiles with cabal throwing an error with `ghc-mod check` and probably more nasty things that I haven't thought of.

Now I tried fixing this in #218 by using the `LocalBuildInfo` generated and written to disk by `cabal configure` which contains all the finalized `package-version-id` dependencies that Cabal decided to use. However this approach proofed problematic as Cabal is very picky about not letting you parse the `dist/setup-config` file containing all this information if the library versions don't match. Normally this wouldn't be a problem as we could just require users to use the same version of the Cabal library for ghc-mod as they use for cabal-install. Unfortunately this fails in the very likely case where a user has upgraded cabal-install and or Cabal (the library) to a version later than the one that's bundled with ghc.

While normally that situation doesn't seem to lead to any issues we have a problem since we depend on ghc which in turn depends on the exact version of Cabal bundled with it at build time which in turn makes it impossible for us to depend on the version of the Cabal library the user is actually using to run `cabal configure`.

I still think that using the information provided by cabal instead of "doing our own thing" is the way to go for deciding which exact packages we should depend on and I've come up with an approach that might work a whole lot better than my previous attempt.

Basically the problem is that `dist/setup-config` is generated by `show`ing the whole `LocalBuildInfo` structure which is made up of a lot of other types internal to Cabal. If any of those types would change we can't parse the file any more which is why Cabal notes the version of the library used to generate the file.

My Idea is that instead of `read`ing the whole `LocalBuildInfo` structure we could just extract the part of `dist/setup-config` that we actually need (through manual string processing), `read` it normally and hope that the type of this sub part doesn't change too much.

I'll update this brach as I work on this, I just posted it so we can have a discussion.