Do not embed Themis, Soter, and cryptographic backend (if present)
into libthemis_jni shared object. Instead, link it dynamically
against Themis like a proper library.

It has been a nice experiment to provide self-contained library for
Java. However, we are going to distribute the library as a proper system
package and for that we will need to have it properly linked against its
dependencies. Themis Core will be installed by the package manager so
all dependencies are going to be satisfied.

These are currently used by Themin JNI wrapper in order to operate
secure_session_load() correctly. Strictly speaking, we should not
be using these functions, but currently there is no way to allocate
Secure Sesssion instance suitable for secure_session_load() without
using private header <themis/secure_sesssion_t.h>. These functions
are exported from the shared library, but we make no commitment to
keeping them exported. The should be hidden back once
secure_session_load() gets a better API.

On the other hand, why not? It's not that hard to implement and
this *is* a wart in the API. Let's mark these private functions
as such so that there is no confusion.