Application.mk: Use latest toolchain version, 4.7
set NDK_PLATFORM_LEVEL & NDK_TOOLCHAIN_VERSION only in jni/Application.jni

This makes the external/Makefile get the values of these two variables from
the official Android place to set them, keeping the build systems in sync.

NDK platform level, aka APP_PLATFORM, is equivalent to minSdkVersion.

http://stackoverflow.com/questions/14551113/android-ndk-multiple-api-levels
set the NDK APP_PLATFORM based on minSdkVersion in AndroidManifest.xml

This way we avoid annoying, arcane build errors caused by different parts
of the build being built for different platform levels.
document the requirement for deps to be installed on the build system
update to sqlcipher v2.2.1
handle init errors when mounting

requires latest changes from libsqlfs
use NDK_TOOLCHAIN_VERSION=4.6 for broad compatibilty across NDK versions

4.7 has already been removed from the NDK, replaced by 4.8.  4.6 is the
default, and labeled the 'stable' compiler.
include custom ant rules to make javadoc: `ant javadoc`

Not much to see here, but should be useful in the near future.
include binary shared libs that are used only for linking against

In order to build the native parts, they need to be linked against openssl
and SQLCipher.  For deployments, these libraries are provided elsewhere, so
include binaries in git that are good enough for linking against.

libcrypto.so came from android-15 4.0.3 emulators from the Android SDK.
libcrypto.so is included in Android itself, and automatically loaded before
any Android app is started.  Therefore, we just need to link against it, it
should never be shipped with the app!

libsqlcipher_android.so came from SQLCipher+for+Android+v3.1.0.zip SHA-256:
9568592f14d8b28d586b742cebb4e032f1f42888a67cdb4685b217d1285a1dbd
run native build as part of the ant build process

This means all you have to run in `ant clean debug`
Eclipse ADT wants to update .classpath again...
update sqlcipher submodule to v3.1.0, same as included libsqlcipher.so

Keep the headers and the shared lib in sync for clean linking.
attempt to fix tests with proguard tweaks

https://stackoverflow.com/questions/5701126/compile-with-proguard-gives-exception-local-variable-type-mismatch
run Eclipse's "Organize Imports" with Android code formatter
code Eclipse code formatter in Android mode on all Java code
suppress lint warnings about not overriding on Android < 9

Since Java 1.6 was not complete in Android until android-9, some of the
methods in this File class do not exist in the Android File class and lint
was complaining about it.
directly read dbFileName from Java in JNI; purge VirtualFileSystem.init()

Though it was a painful process getting through the JNI, this takes us in
the right direction in terms of clean code.

Also rename to dbFileName everywhere to match the name in Java, and make it
static since there can only be one open IOCipher VFS at a time.  And that
also means there is no point in making VirtualFileSystem implement
Comparible.
VirtualFileSystem now a singleton, only one mount can be active at a time

Since the current state of this code is that there can only be a single
virtual file system mounted at a time, convert VirtualFileSystem to a
singleton to make this fact clearer.

closes #3403 https://dev.guardianproject.info/issues/3403
update libsqlfs submodule to get new raw key API

libsqlfs now as separate methods for opening using raw key data, which
SQLCipher will use directly, or using a password, which SQLCipher will use
to derive a raw key with.

refs #3174 https://dev.guardianproject.info/issues/3174
expose new raw key API in Java, to work better with CacheWord

CacheWord generates the raw key based on a dynamic number of iterations of the
KDF, so that it doesn't take ridiculously long on old devices, but on new
devices has a reasonable number of KDF iterations.  The exposes that API into
IOCipher's Java interface for easy integration with CacheWord.

Also, using byte[] for storing passwords means that Java code can zero out the
memory after the password/key is no longer in use.  Strings are immutable in
Java, so the memory cannot be zeroed out. byte[] are very mutable, so they can
easily be zeroed out after use.  Therefore only accept the database key as a
byte[] to encourage people to wipe the key from memory when they are done with
it.

fixes #1713 https://dev.guardianproject.info/issues/1713
fixes #2254 https://dev.guardianproject.info/issues/2254
refs #3174 https://dev.guardianproject.info/issues/3174