When the "fips-link-precompiled" feature is used, the build script for
boringSSL (`boring-sys/build.sh`) adds a precompiled `bcm.o` module
provided by the user. The module is renamed to `bcm-fips.o` and inserted
into `libcrypto.a` just before the `bcm.o` built by the script. The
intent is to "shadow" the module so that, for any symbols that are
provided by both, the linker picks the implementations provided by
`bcm-fips.o`. At the same time, any sybmols in `bcm.o` that are not in
`bcm-fips.o` can be used.

This configuration requires special flags in order to tell the linker
how to resolve duplicate symbols (RUSTFLAGS="-Clink-args=-Wl,-zmuldefs"
is sufficient). However even with these flags thare are certain symbols
that don't resolve. In particular `bcm-fips.o` expects `bcm.o` to
provide `RAND_need_entropy`.

Rather than attempt to cobble together a working version of this
"shadow" build of `libcrypto.a`, we modify the build script so that it
"replaces" `bcm.o` with the precompiled module provided by the user.
Based on internal conversations, this appears to be sufficient for every
use case for these bindings. If the shadow build is required, then the
user will need to provide their own version of `libcrypto.a` (This is
not supported as of this commit.)

One more change is required in order to build with
"fips-link-precompiled". Building fails because the FFI exports a
different API than the bindings expects. To fix this, it is sufficient
to change the features so that "fips-link-precompiled" does not imply
"fips".

We expect `fips::enabled()` to be set when the "fips-link-precompiled"
feature is used.