Unify the two BoringSSL codepaths a bit and simplify init

[davidben]

Although bssl-sys (currently) provides init, it only does so for rust-openssl, and it's more natural for rust-openssl to consistently be responsible for it. Also BoringSSL has not required initialization at all since June 2024.

I've also removed the ambiguous_glob_reexports allowance. I couldn't reproduce whatever triggered it, and it seems unlikely that the two codepaths would have different needs here.

This leaves the remaining non-build unstable_boringssl trigger so minor that perhaps we should just remove it here? It dates to some problematic Android Rust integration. At this point, it's just an external mechanism to get the same output as the build.rs logic around bindgen, mostly because bindgen has perpetual deficiencies w.r.t. correctly binding C, so we need to work around it. Ideally there wouldn't be two sources of those workarounds, but Google's build environments care about build reproducibility and hermeticity, while Rust and Cargo have... very much not achieved this yet. But there's no reason for rust-openssl's build to care about this.

[alex]

I don't have a sense of who the users of the boringssl support here are besides you guys and us :-) We use the bindgen path but uhh, I guess we'll keep the unstable_boringssl stuff as long as you don't mind maintaining it?

[alex]

This is a good cleanup regardless, thanks! (And thanks for making a library without initialization APIs.)

[davidben]

Well, it's extra silly because unstable_boringssl does not reflect what Android are doing anyway. They're actually using bssl-sys to swap out openssl-sys rather than the bindgen output. (But I suspect, since you all still use openssl-sys, they should too.) Anyway, piles of things to fix later.