Clang-sys shouldn't use "link" in the manifest

[Jeremy Fitzhardinge]

The link attribute in the manifest causes cargo to enforce that the named library is globally unique in the package dependency graph.

There are several problems with this:

1. When clang-sys is used with the runtime feature, it has no link-time dependency on libclang - it links and loads it at runtime with dlopen or equiv. Ideally link should be conditional on a feature, but that's not currently possible.
2. The Cargo check is too coarse, and only applies at the pkg resolution level rather that at the individual target level. This means it fails spuriously if two different buildscripts are linked against different versions of clang-sys, where there's no possibility of any conflict.
3. Even if you were't using runtime, then the different versions of clang-sys would likely be using the same underlying libclang native library, so there's no actual conflict. This is exacerbated because clang-sys is using version numbers < 1.0, and users specify constraints such as ^0.23 (eg, bindgen). Since ^0.23 is not semver compat with 0.28, Cargo ends up resolving to two distinct versions of clang-sys, even though they'd end up linking the same underlying library and (should be?) API compatible. If clang-sys were 1.x, then ^1.1 and ^1.2 would resolve to the same version.

[Kyle Mayes]

v1.0.0 has now been released which should hopefully make this no longer a problem for future released and this has been worked around for previous released as discussed in #96.