Introduce a subproject ":android" for AndroidThemis builds. We can't
continue using top-level build.gradle for everything if we are going
to use Gradle for Desktop Java too.

This changes the invocation strings for targets which now need to be
qualified (by prefixing ":android:...").

Leave the top-level file with some common definitions. This allows to
not write them in each subproject and to use "./gradlew" right from
the repository root.

Add a subproject ":desktop" for 'Desktop Java' builds of JavaThemis.
This will produce a JAR with Java bytecode only, suitable for use by
desktop Java projects.

You can build it with

    ./gradlew :desktop:build

and collect artifacts from "src/wrappers/themis/java/build/jar".

The resulting JAR file is named "java-themis" because the name "themis"
is already taked by AndroidThemis.

Debian stable has upgraded its default Java version to 11. Gradle 4.X
does not support Java 11. This version is supported only since 5.0.
Upgrade to latest Gradle 5.X version.

Note that *the latest* version branch is Gradle 6.X. We won't jump
versions that fast.

Gradle 5.X requires Java 8 (previously it required Java 7). This cuts
some older systems that ship with only Java 7:

  - Debian 8 "Jessie" - oldoldstable, no security support since
    June 2018, LTS support lapses in July 2020

(Only for JavaThemis, obviously.)

By default Gradle will configure all subprojects of a top-level project.
For us that means that we'll force AndroidThemis configuration even if
the user is trying to build JavaThemis for desktop. That will require
a properly installed and configured Android SDK, completely unnecessary.

Thankfully, Gradle also have an experimental "configure on demand"
mode which will configure only the projects actually requested and
needed for the build. Enable this feature. It is 'experimental' but
this means that it might not work for some projects, but Gradle team
plans to make this mode the default one. It works for us, so it's okay.

We build JavaThemis with deprecation warnings enabled. Object finalizers
are deprecated since Java 9. In our case we genuienly need finalizers to
prevent native memory leaks so suppress these warnings.

The "build" target already runs tests if they are set up. Configure
JUnit test compilation and runner.

Note that JavaThemis requires JNI library to be loaded. By default it is
installed into a location that is not present in the Java library search
path. We need to explicitly add "/usr/local/lib" to "java.library.path"
property. Also note that Gradle will run JUnit stuff in a separate JVM
so we need to pass the system property to that JVM from the main one.

Every class having native methods should have a System.loadLibrary()
call so that if only that class is loaded by JVM, the native library
is also loaded correctly.

It kinda worked before because typically users and tests load other
classes, but if *only* SymmetricKey is loaded then it failed to locate
the native method. (For example, JUnit might run each test in separate
JVMs which load only necessary classes.)

Use common properties to have a single place we need to update when
doing a release.

Update Gradle support library to the latest stable version. Update
Gradle wrapper to the latest patch version too (required for some of
others updates). And update the Android test runners as well.

New test runners require AndroidX property to be enabled in the
properties file so add that as well.

Suggested by Android Studio too.

Android Studio recommends using current latest stable version 3.6.3, but
it seems to have some issues with NDK version detection. Since we have
different NDK versions in our CI environments, we can't use the version
which fails to work with them.

Gradle tools v3.6.3 fail the build and require a particular version of
NDK, for example:

    * What went wrong:
    A problem occurred configuring project ':android'.
    > No version of NDK matched the requested version 20.0.5594570. Versions available locally: 21.0.6113669

Version 3.5.X does not seem to have such issues, so let's use it then.

It seems that 3.5.3 does not work either. I don't want to spend more
time on this discretionary upgrade, so just revert to the version which
is known to work and let's keep it pinned that way until we need to
upgrade to have some new features or bug fixes.