Allow easy measurement-kit integration on Android

[bassosimone]

#1. Compile libight for Android

The first problem to solve is how to compile libight for Android. One option is to use the Android.mk and Application.mk files, as we do today. However, I'd rather use the autotools-based build system, to avoid maintaining two build systems and because this is in any case the way to go to compile Tor (which sooner or later we'll need to integrate, since Tor is needed to publish ooni reports).

A quick research (thanks, @alessandro40, for doing that) indicates that there are ways to convince the Android build system to compile something the autotools way. We should investigate further.

Regardless the way we choose, there is the problem that IIRC we could not cross-compile libight for Android using clang because the linker failed to find some libyaml-cpp symbols.

I guess we should just try with gcc and see what happens. By the way, switching to gcc we'll also remove the need to maintain a separate libevent repository for Android, since the latest stable version of libevent cross-compiles for Android using gcc.

Update [2015-11-11]: this part has now been done and merged into master.
#2. Integrate Java code with C code

Android applications are written in Java whereas libight is written in C++. The standard way to interface Java code with C/C++ code is JNI. SWIG helps a lot because it auto-generates JNI code from C/C++ headers.

Therefore, SWIG may be the way to go. I recall that one can register Java callbacks for C objects using a SWIG feature called directors but I don't know if this also extends to the std::function<> callbacks that we use so extensively; nor I know whether SWIG supports C++11. These are things that we should check after we have successfully compiled libight for Android... a good starting point could be this document describing the status of SWIG support for C++11.

Another, orthogonal option (again thanks for @alessandro40 for preliminary research) is to do like Orbot; compile a binary that is saved in the resources directory and then execute it. If we follow this alternative approach (which I like less than the previous because I'd rather follow the same approach on both iOS and Android), we need to create some extra software that provides a main() for libight and interacts in some way with its caller. As a side note, it's not recommended to fork on Android.

Update [2015-11-11]: Working on this in #200. I am not currently using SWIG and have designed a rather simple JNI API that avoids mixed Java/C++ objects for simplicity.

[bassosimone]

Part 1, i.e. compiling measurement-kit on Android, is now done. We're working to find out the best way to integrate measurement-kit with Android Java, see #192.

[bassosimone]

I've discussed the proper way to release a library for Android (i.e. publishing a .aar file on jcentral) in the discussion of pull request #275. See also: http://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en

[bassosimone]

I think we can now close this pull request since we've taken the route of adding simpler JNI wrappers for MK tests, currently available as measurement-kit/measurement-kit-android.