[Android] Fix method invocation and wrappers cleanup handling in Java Bridge

[Android] Fix method invocation and wrappers cleanup handling in Java Bridge

While investigating flakiness of JavaBridgeBasicsTest#testRemovalNotReflectedUntilReload
I realized that we don't handle invocation of injected objects' methods
properly -- InvokeMethod was bound to a GinJavaBridgeObject instance and was
making two wrong assumptions:
  - that the method can only be called for the wrapper where the method has been
    obtained from -- not true, as it is possible to use `call()` method of
    `Function` to pass a different `this` object;
  - that it is safe to store an unretained pointer to GinJavaBridgeObject --
    it's not, as it is possible to retain a function representing method
    separately from the injected object, which can be collected (if it's not a
    named object).

The issue that was causing the test flakiness originated from the fact that
DidClearWindowObject can be called several times during the page lifecycle.
GinJavaBridgeDispatcher injects new wrappers each time, this isn't a problem
on its own, but leads to premature issuing of wrapper deletion notificiations
when the wrappers of the old generation got cleaned up.

BUG=468679
Committed: https://crrev.com/9e4422ed1a5babde895ab2c101298e69338fdfc2
Cr-Commit-Position: refs/heads/master@{#321567}

[mnaganov (inactive), 2015-03-19 18:09:14]

mnaganov@chromium.org changed reviewers:
+ torne@chromium.org

[Torne, 2015-03-20 12:16:32]

LGTM in general, but I have one question: you forbid calling an injected method
on a non-injected object, but what happens if you call an injected method on an
injected object of a different type? Does that do something reasonable?

[mnaganov (inactive), 2015-03-20 12:55:29]

On 2015/03/20 12:16:32, Torne wrote:
> LGTM in general, but I have one question: you forbid calling an injected
method
> on a non-injected object, but what happens if you call an injected method on
an
> injected object of a different type? Does that do something reasonable?

Technically it's the same as attempting to call a non-existent method of
an injected object, which would throw an exception, and we have a test for that.
But just in case, I have added a dedicated test for using `call()` method.

[mnaganov (inactive), 2015-03-20 12:57:13]

mnaganov@chromium.org changed reviewers:
+ jochen@chromium.org

[mnaganov (inactive), 2015-03-20 12:57:14]

jochen@: Please consider approving content/ changes.

[jochen (gone - plz use gerrit), 2015-03-20 13:00:10]

lgtm

[mnaganov (inactive), 2015-03-20 13:03:33]

The CQ bit was checked by mnaganov@chromium.org

[mnaganov (inactive), 2015-03-20 13:03:34]

The patchset sent to the CQ was uploaded after l-g-t-m from torne@chromium.org
Link to the patchset: https://codereview.chromium.org/1018413002/#ps20001
(title: "Added a dedicated test for attempting to call a non-existing method via
`call`")

[commit-bot: I haz the power, 2015-03-20 13:03:40]

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

[commit-bot: I haz the power, 2015-03-20 14:27:15]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-20 14:28:07]

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