Dynamic linking, CT target selection

API changes

• From now on just import the llvm module.
• Switch from dynamic loading to dynamic linking;
  LLVM.load is thus no longer needed (and is,
  in fact, also not available anymore), you need
  to link against the correct libraries from this
  release onwards. This will be either one library,
  if LLVM was built as a single dynamic library, or
  several, in case LLVM was built with one library
  per module. In the latter case you'll need to identify
  which libraries to link against yourself, but a good starting
  point would be examples/fibonacci/dub.json and LLVM's module documentation.
• LLVM Targets: llvm-d makes no automatic assumptions about which
  targets LLVM was compiled with (and are thus available in
  the dynamic libraries). You need to provide llvm-d with
  the targets yourself by setting appropriate compile time
  D versions (the same way that you do it for version of LLVM itself):
  The D version LLVM_Target_XyZ instructs llvm-d to assume
  that the LLVM Target XyZ will be linked in and provide appropriate
  initialization for it; notice that the target name is case sensitive.
  For now, llvm-d's dub package comes with two configurations:
  • native-target: Instructs llvm-d to assume the native target for
    the current platform will be linked in.
  • no-target: Provides no target assumptions to llvm-d.

Why switch to dynamic linking?

Support for platforms on which LLVM is built with one library per module while retaining dynamic loading would require mapping functions pointers to libraries they should be loaded from;
this would require a non-negligible amount of boilerplate code, especially since there's no guarantee that such a mapping were to remain stable for later releases of LLVM.
So instead of introducing even more boilerplate code, I judged it more practical to switch to dynamic linking, which incidentally also gets rid of a significant amount of existing boilerplate code.