Detect shared library name with llvm-config

[RyanGlScott]

Currently, llvm-general's Setup.hs script hardcodes the name of of the shared LLVM library based on its version number (e.g., with llvm-3.9, it hardcodes LLVM-3.9). The problem is that the MinGW-w64 (Windows) version of LLVM doesn't put version numbers at the end of its library files - that is, it names it libLLVM.dll.a instead of libLLVM-3.9.dll.a. As a result, llvm-general fails to configure on Windows because it can't find the right shared library name:

$ cabal configure -fshared-llvm
Resolving dependencies...
Configuring llvm-general-3.9.0.0...
Warning: Instead of 'cc-options: -IC:\msys64\mingw64/include' use
'include-dirs: C:\msys64\mingw64/include'
setup.exe: Missing dependency on a foreign library:
* Missing C library: LLVM-3.9.1
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.

See https://github.com/AccelerateHS/accelerate/pull/342#issuecomment-274116175 for an example of where this problem arose.

What seems like the obvious solution here is to instead just determine what the shared library name is from llvm-config, like Setup.hs currently does for the static library names. This PR does just that.

Note: I'm unfamiliar with how PRs for this library are supposed to work, since there's one branch for every LLVM version. Since I happen to have llvm-3.9 installed, I opened this PR on the llvm-3.9 branch. If you'd prefer that it be done differently, please let me know.

[RyanGlScott]

It is unlikely that this will ever be fixed.