In JSStackFrame::GetMethodName() we try to infer a useful method name to
show for the closure to which the stack frame belongs. This is done by
first considering the functions name, and checking if the receiver has a
property with that name and if that property's value is the closure. In
case the function doesn't have a name or the property's value is not the
closure itself, we fall back to a reverse lookup of the closure within
the object (and its prototypes).

This CL speeds up this logic by attacking two problems:

1. The reverse lookup was performed by first using the KeyAccumulator to
   extract the names of all enumerable properties, and afterwards using
   the LookupIterator on each name, and testing the resulting property
   value against the closure. This is fairly slow and creates a lot of
   temporary objects and handles. We now look into the descriptor arrays
   or dictionary backing stores of the objects directly instead, which
   is easily 2-10x faster.
2. For the common case of `o.foo = function() { ... }` the parser already
   places an "inferred name" of `o.foo` onto the SharedFunctionInfo,
   which we can use as a hint to infer the name of the function instead
   of immediately falling back to the expensive reverse lookup.

This repairs the regression reported in http://crbug.com/1069425 and
recovers most of the slowdown reported in http://crbug.com/1077657
(there's still some overhead left from the async stack trace tracking).

Fixed: chromium:1069425
Bug: chromium:1077657
Change-Id: I88d23ccad123906df70c5217e815493106e03ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72545}