Use env var to get ghc libdir

[jneira]

• This a quick and dirty solution to Using ghc-paths makes downstream executables non portable #96
• The proper solution would be (described in the issue):

the direct solution i can think off is pushing the ghc wrapper (better then the libdir location imo) or the data that is extracted using it (dynflags and...) downstream and require client code to provide it, in a new function (or several), falling back to the actual one

But the ghcWrapper is used in:

• parseModuleFromString and parseModuleApiAnnsWithCpp in Language.Haskell.GHC.ExactPrint.Parsers
• and in a dozen of functions in Test.Transform (we dont have to worry about those ones)
• a pair of functions in InsertSignature (it is an example and we can ignore them)

Create duplicate versions of both parse* and push them downstream (in the lib and the downstream packages) will be non trivial.
Using the system env as a global variable is dirty (but arguably better than the fixed at compiled time actual libdir) but quick and dont require changes in downstream packages.

I am not pride of this so i will understand if it is not accepted 😄

[alanz]

I will hold my nose and merge.