Add ScriptValue.v8ValueUnsafe() to access the V8 value without cross-context access check.

Add ScriptValue.v8ValueUnsafe() to access the V8 value without cross-context access check.

In DevTools instrumentation we may need to access an async stack trace object
wrapped into a ScriptValue from a different world. We would unwrap it to a
native object only to get it's String and number members, and not passing the
object to user's scripts.

BUG=396916
R=yurys

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=178944

[yurys, 2014-07-24 11:15:21]

This way you will expose access to objects from different context through
JavaScriptCallFrame. No one will stop you from getting say the frame's
scopeChain. I don't think we should go this way. Why do you need to pass
JavaScriptCallFrame to another context?

[yurys, 2014-07-24 11:16:09]

If it is just for serializing the frame we should be able to do it in its
original context.

[aandrey, 2014-07-24 11:23:26]

On 2014/07/24 11:15:21, yurys wrote:
> Why do you need to pass JavaScriptCallFrame to another context?

I don't need to pass JavaScriptCallFrame to another context.
I just need call frames' functionName, scriptId, line&column numbers.
As I said, JavaScriptCallFrame that we store may well come from another context,
thus we hit the RELEASE_ASSERT.

> I don't think we should go this way.

I'm open for other ideas.

[yurys, 2014-07-24 11:54:30]

On 2014/07/24 11:23:26, aandrey wrote:
> On 2014/07/24 11:15:21, yurys wrote:
> > Why do you need to pass JavaScriptCallFrame to another context?
> 
> I don't need to pass JavaScriptCallFrame to another context.
> I just need call frames' functionName, scriptId, line&column numbers.
> As I said, JavaScriptCallFrame that we store may well come from another
context,
> thus we hit the RELEASE_ASSERT.
> 
> > I don't think we should go this way.
> 
> I'm open for other ideas.

Afetr discussing this offline I'm OK with this approach or making
JavaScriptCallFrame a friend of ScriptValue. lgtm.

[aandrey, 2014-07-24 11:56:41]

@haraken, are you OK with this change?

[aandrey, 2014-07-25 15:56:47]

ping?

[haraken, 2014-07-25 16:00:34]

Sorry, I missed this.

LGTM.

[aandrey, 2014-07-25 16:02:08]

The CQ bit was checked by aandrey@chromium.org

[commit-bot: I haz the power, 2014-07-25 16:02:33]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/aandrey@chromium.org/418823002/1

[commit-bot: I haz the power, 2014-07-25 17:11:17]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/33359)

[commit-bot: I haz the power, 2014-07-25 17:39:40]

Change committed as 178944