• Add API support for LLVM 8
• When using dynamic loading, you can now specify multiple libraries to search through via LLVM.load, e.g.
  LLVM.load("libLLVM.so", "libLTO.so"). This change was required to support dynamically loading lto/thinlto functionality, which is generally not available through the main LLVM shared library. Due to this, you can also now dynamically load when the main shared library has been split into multiple shared libraries, just list all of them. If auto loading is used or no libraries are passed toLLVM.load then llvm-d will now also try to load the LTO shared library.
• Backwards incompatible change of default behavior: When dynamically loading without explicitly set filename(s), search for a main LLVM shared library without the version in its name (so e.g. libLLVM.so instead of libLLVM-8.0.0.so).

llvm-d 1.x to llvm-d 2.x moved from dynamic loading to (dynamic/static) linking.
This readds support for dynamic loading via compile time introspection.

• Single shared library only (e.g. libLLVM-X.Y.Z.so)
• Switch from (dynamic/static) linking to dynamic loading by
  setting the D version LLVM_Load.
• Use LLVM.load / LLVM.unload for manual control over which
  shared library to use
• Additionally set D version LLVM_Autoload to try to load a
  platform appropriate default shared library for LLVM
• As compile time introspection is used to generate function pointers
  dynamic loading has increased compilation time.

Special thanks to everyone who provided feedback on how to optimize the cost for the dynamic introspection

Thanks go to @foerdi for doing the annoying part.

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.