When building with ENGINE=boringssl, Soter embeds BoringSSL into its
libraries, including static ones. This enables the users to link only
against libthemis.a and libsoter.a, without having to salvage the
BoringSSL binaries from the build directory (which are *not* included
into packages).

What is the issue here?
-----------------------

However, embedding BoringSSL has a side effect. Due to the way static
linkage works, all BoringSSL symbols from "libsoter.a" are
indistinguishable from Soter symbols for exporting purposes. That is,
any binary linked against "libsoter.a" will by default include and
export all BoringSSL symbols. This is problematic because it can cause
symbol conflicts. Dynamic libraries are not affected by this because
we control what symbols are exported. That way BoringSSL stays inside
Soter library and does not cause conflicts.

In order to avoid conflicts, start using BoringSSL's symbol renaming
facility. EVP_sha256() will be renamed into SOTER_0_14_0_EVP_sha256()
and all call sites from Soter will refer to this new symbol instead.
This makes Soter's BoringSSL copy independent of any WhateverSSL is
there in the binary.

How renaming works
------------------

Bad news here is that renaming requires building BoringSSL twice. First
we build it to enumerate the symbols to rename, then it is built again,
now with renamed symbols. All symbols need to be renamed, not only those
used by Soter, because the entire BoringSSL library is embedded into
Soter. We cannot simply enumerate and hardcode what we use.

After building BoringSSL with renamed symbols, Soter needs to use them
in renamed form. For that it needs to be built with BORINGSSL_PREFIX
define and <boringssl_prefix_symbols.h> in its include path. That header
will perform actual renaming using C preprocessor.

Other build details
-------------------

Previously Soter did not care about build order, but now BoringSSL needs
to be built (possibly renamed) before Soter can be built.

Note that extracting symbols with BoringSSL tool requires Go. BoringSSL
build itself requires Go so this is not a new dependency.

Enable BoringSSL symbol renaming by default for Linux and macOS desktop
builds and disable it for WebAssembly builds.

AndroidThemis also uses BoringSSL, but it does not use Themis Makefile
for that. It does not use renaming either.

Renaming is important only for the case of static libraries, and only
desktop systems provide them in packages. Mobile systems use dynamic
linkage for the most part and avoid symbol conflicts.

The default can be overridden from the command line:

    make ENGINE=boringssl RENAME_BORINGSSL_SYMBOLS=no

or "yes" to enable it.