v4 -> v5 upgrade path

Cargo won't allow boring-sys v4 and boring-sys v5 coexist in one project (thanks to `links` property), which generally is a good idea, because their C symbols would conflict. However, this means that projects can't upgrade to boring v5 if any of their dependencies use boring v4. Such all-at-once upgrade is much harder and gets slowed down by the slowest-to-upgrade dependency.

It's relatively easy to make boring v5 support being used with boring-sys v4, but it's the less interesting combination, since the sys crate is more important to upgrade.

Unfortunately, making boring v4 use boring-sys v5 is more complicated. We can't simply release a version of boring v4 that accepts both versions of the sys crate, because the sys v5 crate has has only a subset of sys v4 functionality. `cargo update` eagerly picks the latest version of dependencies, so it would be a breaking change.

I can't simply use a feature flag as an opt-in to sys v5, because Cargo is overly restrictive with `links`, and wants to make a single universal `Cargo.lock` that takes into account even optional disabled dependencies.

Given the limitations, my current idea is to release a version of `boring-sys` v4 that doesn't have a `links` property, but optionally depends on `boring-sys` v5. Make it skip its own build and re-export v5 crate when a feature flag is enabled. This will be easier to test once v5 is on crates.io, so we should release v5 first.