[Android] Add an out-of-app instrumentation driver APK.

testing/android/test_support.gyp

+
+{
+  'conditions': [
+    ['OS=="android"', {
+      'targets': [
+        {
+          'target_name': 'test_support_java',

[Yaron, 2015/04/07 15:39:04]

There's already base_java_test_support and content_java_test_support so this is
getting confusing. Any reason not to include in base_java_test_support?

Further, in general, we don't break up a folder of java code into multiple
packages: i.e. chromium/test/driver, chromium/test/support are different
libraries. I think Chris has thoughts about making one java dir for everything
but until then I think it's clearer to separate top-level java folders as
projects and not packages within one. ISTM that you have two separable concepts:
a driver and a support library for use with that driver

[jbudorick, 2015/04/07 19:24:45]

This is used both in base_java_test_support and in build/apk_test.gypi because
it's used by both the gtests and instrumentation tests to dump results in a
format that Appurify understands.
I had thought that that was a product of gyp's quirks, but I don't have any
objections to splitting these into separate top-level java folders. Created:
  testing/android/appurify_support
  testing/android/driver
  testing/android/native_test
  testing/android/passenger
  testing/android/reporter

Moving the preexisting code to testing/android/native_test added quite a bit to
this CL. I'd be open to splitting that into a separate CL; wdyt?

+          'type': 'none',
+          'variables': {
+            'java_in_dir': '../../testing/android/java/src/org/chromium/test/support',
+            'java_in_dir_suffix': '',
+          },
+          'includes': [
+            '../../build/java.gypi',
+          ],
+        },
+      ],
+    }],
+  ],
+}