Fix gn jni generation rules for Android

Fix gn jni generation rules for Android

The GN rules for the JNI generator currently generate the --includes
argument (that is, the #include line which gets emitted in the
generated jni.h header) in the following way:

generate_jni: always relative to the src root (e.g., content/foo/bar.h)
    this is achieved by rebasing the jni_generator_include against //.

generate_jar_jni: relative to on root_build_dir (typically out/Release,
    hence ../../content/foo/bar.h). This is achieved by rebasing the
    jni_generator_include against root_build_dir.

generate_jni is fine, but relies on the target having set the root
src/ dir in the include path. The latter, instead, happens to work
only by accident because the targets that currently use it (currently
just surface_jni_headers) happen to have an include path which is at
distance two from the root src/ (so the generated #include
"../../base" happens to work).

This CL fixes both cases and causes the generated include to be always
relative to the destination folder of the generated header
(jni_output_dir). Furthermore, this change removes the dependency on
the generated header path. Rationale: the file itself is not an input
for the generator, the --include string gets just copied and pasted
into the generated file. Hence, the generator should not be re-run if
the contents of the jni_generator_helper.h changes.

Committed: https://crrev.com/9d6b1606854a8786e94858e1f65b2ae451e58ddf
Cr-Commit-Position: refs/heads/master@{#325604}

[Primiano Tucci (use gerrit), 2015-04-16 17:13:41]

primiano@chromium.org changed reviewers:
+ cjhopman@chromium.org, torne@chromium.org

[Primiano Tucci (use gerrit), 2015-04-16 17:13:42]

Chris,Torne can you PTAL to this.
Rational for doing this: ssid@ in our team was trying to use generate_jar_jni in
base/ and, after some long investigations, realized that the generated jni
header had a wrong path.
In gyp the generated include was:
#include "base/...."
in Gn (before this change) was:
#include "../../base/...", but there is no include path in base which resolves
the ../../.

After this change the path looks like
#include "../../../../../../../base/..."
which should be the right thing to do (I hope)

[cjhopman, 2015-04-16 20:32:56]

lgtm

[Primiano Tucci (use gerrit), 2015-04-17 07:08:27]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2015-04-17 07:09:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1093643002/1

[commit-bot: I haz the power, 2015-04-17 07:13:05]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-04-17 07:13:58]

Patchset 1 (id:??) landed as
https://crrev.com/9d6b1606854a8786e94858e1f65b2ae451e58ddf
Cr-Commit-Position: refs/heads/master@{#325604}