Re-land CL 9466047.

Re-land CL 9466047.

Main change from the original CL: Call::ComputeTarget does not use IsProperty
anymore, because this would potentially need a holder, which we don't have
here. Using Map::LookupInDescriptors with a NULL holder is a bit fishy in
general, because one has to be *extremely* careful when using its LookupResult.

The original CL made Chrome's NetInternalsTest.netInternalsTourTabs browser test
fail, but it's a mystery how this could happen: We should never reach
Call::ComputeTarget via Call::RecordTypeFeedback with a CALLBACKS property,
because we never consider calls to them monomorphic, which is in turn because of
the stub cache leaving them in the pre-monomorphic state. Therefore, I don't
have a clue how to write a regression test for this...

As an additional tiny bonus, the --trace-opt output for deoptimizations has been
improved.

Committed: https://code.google.com/p/v8/source/detail?r=10906

[Vyacheslav Egorov (Chromium), 2012-03-02 10:18:45]

LGTM but I would prefer to have a regression test.

What happens if we have IC that is already in megamorphic state and them we pass
an object with accessors (API ones, because we don't compile IC stub for
JavaScript ones AFAIK) into it. Then trigger optimization. Would it find stub
for accessors in stub cache?

[Vyacheslav Egorov (Chromium), 2012-03-02 10:20:12]

actually another thought: we don't have call-site precise information for
polymorphic ICs so it's enough that we have IC stub compiled for CALLBACKS
property in some other place.

[Vyacheslav Egorov (Chromium), 2012-03-02 10:20:41]

s/callbacks property/callbacks property with the same name/

[Erik Corry, 2012-03-05 07:09:08]

I would very much prefer if a CL description included a mention of which issue
the change fixes.