Adds a link check in to the LLVM find script to make sure it can actually link against the library it finds.
Noticed this issue since I have a non-standard LLVM version built and installed.

For some dumb reason, llvm-config doesn't provide the flags to link
against the dynamic library copy of LLVM (as opposed to static), so the
script has to guess the library name.  However, in some installations
(such as mine), there is no dynamic copy, which caused Dolphin to fail
to link.  Change the script to do a link test.  If it fails, one option
would be to fall back on static linking, but I just have it fail to
detect LLVM, because statically linking Dolphin against LLVM is really
not a great idea - huge binary, long link time.

We require LLVM 3.4 minimum, so if the user has something older make sure to not attempt compiling.
Fixes issues #7858 and #7906.

$(llvm-config --ldflags) was passed to the compiler but it needs to be
passed to the linker instead (-L and -l flags).

I must have had a dirty cmake configuration which didn't encounter this issue.
Make sure we are using LLVM_DEFINITIONS to know where we are linking to libraries at.
Link against libLLVM-${VERSION}, the other one was linking us against static libraries...

This will work for all of our platforms, x86, ARMv7, and AArch64.
Main issue with this is that LLVM's cmake files aren't correctly finding the LLVM install.
Not sure if this is Ubuntu's issue or not, it may just work on other operating systems.

We could potentially improve this, you can pass in a specific CPU in to the LLVM disassembler. This would probably affect latency times that are
reported by LLVM's disassembly? This needs to be further investigated later.