Use runtime clang-sys feature to match cpal

[kcking]

I was getting the following clang-sys failure when using vst3-bindgen in a crate that also depends on cpal:

  thread 'main' panicked at 'a `libclang` shared library is not loaded on this thread', /Users/kevin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/clang-sys-1.6.1/src/lib.rs:1735:1

I think cpal's transitive dependency on clang-sys enables the runtime feature, also enabling it for com-scrape's usage of clang-sys. But clang_sys::load() must be called when the runtime feature is enabled.

We could in theory expose the clang-sys/runtime feature through vst3_bindgen -> com-scrape -> clang-sys if we don't always want it enabled, let me know what you think.

[glowcoil]

Well, that's frustrating. I consider this to be an incorrect use of Cargo features on the part of clang-sys (and it looks like I'm not the first to point this out: KyleMayes/clang-sys#128), as features are supposed to be additive, i.e. enabling a feature of a crate should not break users of the crate who do not have that feature enabled (see the Cargo reference).

That being said, it will probably be very common for vst3-bindgen to coexist in the same dependency tree with bindgen, so I think this is worth doing. I also think it's fine not to bother with a feature for now; we can bother with that if there's actually a need for it at some point. In any case, I appreciate the PR!