FreeBSD uses llvm-config{}{} format

See merge request taricorp/llvm-sys.rs!1

Allow successful builds of docs on docs.rs

Currently `llvm-sys` cannot be built by docs.rs.

### The Situation

This is a problem not only for direct consumers of `llvm-sys` but for any project which transitively includes it.
The problem is that with default flags, `llvm-sys`'s `build.rs` attempts to locate a local install of LLVM, which does not exist in the docs.rs docker image. Rightfully, the build script panics to present this problem to the user.
Frustratingly, `cargo doc` runs the `build.rs` file anyway, and thus fails when LLVM install is not found **despite the fact that docs can be generated without linking to a local LLVM**. 

Further complicating things: There is no way to detect in `build.rs` that, ultimately, we're just trying to generate docs.

### The Solution

It is, however, possible to detect doc builds within the crate itself using `cfg(doc)`. This allows for the following solution:

1. If we don't find LLVM, rather than panicking in `build.rs` we can output `cargo:rustc-cfg=LLVM_SYS_NOT_FOUND` and exit early. This allows build.rs to "succeed" during builds where LLVM is not found.

2. In `lib.rs`, we can detect using `#[cfg(all(not(doc), LLVM_SYS_NOT_FOUND))]` that we are not building docs and emit the compile time error using `std::compile_error!`

If we are building docs, the compilation succeeds. I've tested this on the `docs.rs` docker image and it works great!

See merge request taricorp/llvm-sys.rs!2

LLVM svn is deprecated and no longer sees new release branches. The new
canonical location is on github with git, which doesn't appear to have a
good way to diff remotes (so the best way to do this is now to check out
a copy and diff the branches).

That file is meaningless since the git conversion

The compilation failure message introduced to allow doc builds to
succeed was wrong; correct it.

Fix typo in enum.

See merge request taricorp/llvm-sys.rs!3

Fixes an incorrect spelling for LLVMAtomicRMWBinOpFAdd.

The values are bitflags, which can't be defined as enum variants to use
them correctly.

Fixes #6.

Thes links don't work from the command line when rust tries to invoke
`clang` or whatever the default linker is. This commit addresses it by
removing the `.tbd` suffix and `lib` prefix. Clang will then correctly
find the library and link.

Ensure that we have been told to link a library as `-llib{}.tbd`
before stripping off the leading `-llib` and trailing `.tbd`. This
ensures we don't slice off more than we were expecting to.

Re-write `.tbd` System Library Links

Closes #7

See merge request taricorp/llvm-sys.rs!5

Initial macOS CI configuration.

Macos ci

See merge request taricorp/llvm-sys.rs!6

They're broken (and have been for a long time) and there isn't currently
any interest in fixing them.

This allows users to select one of multiple supported LLVM versions via
feature flags, which is useful although breaks the usual rules around
feature flags (that state that they should be strictly additive).

Helpful to avoid needing to relearn the update process for every new
LLVM version.

Fix build when no-llvm-linking is enabled

See merge request taricorp/llvm-sys.rs!7

Before this change there was a bug where if you used
LLVM_SYS_<VERSION>_PREFIX, build.rs would only look for llvm-config
inside the prefix, and not the other binary candidates
llvm-config-X, llvm-config-X.Y and llvm-configXY.

Additionally with this change, if a prefix is specified, build.rs will
look for llvm-config ONLY inside the prefix. The assumption being that
the user know what they're doing, and may be trying to link to a
specific build or fork of LLVM.

If not prefix is set, $PATH is searched.

Fix bug and ambiguity when using LLVM_SYS_<VERSION>_PREFIX

See merge request taricorp/llvm-sys.rs!8

When both the no-llvm-linking and disable-alltargets-init features are
enabled llvm-config isn't needed, so don't error out.

build.rs: don't error with LLVM_SYS_NOT_FOUND when llvm-config is not needed

See merge request taricorp/llvm-sys.rs!11

On Windows the unsuffixed versions may not exist, so also check for ones
ending in .exe.

Thanks to Ivan Enderlin <ivan@mnt.io> for the original implementation
and pointing out the problem on Windows.