This is another step towards considering the unoptimized frame size in
stack checks within optimized code.

With the changes in this CL, we now keep track of the maximal
unoptimized frame size of the function that is currently being
compiled. An optimized function may inline multiple unoptimized
functions, so a single optimized frame can deopt to multiple
frames. The real frame size thus differs in different parts of the
optimized function.

We only care about the maximal frame size, which we calculate
conservatively as an over-approximation, and track in
InstructionSelector::max_unoptimized_frame_height_ for now. In future
work, this value will be passed on to codegen, where it will be
applied as an offset to the stack pointer during the stack check.

(The motivation behind this is to avoid stack overflows through deopts,
caused by size differences between optimized and unoptimized frames.)

Note that this offset only ensure that the topmost optimized frame can
deopt without overflowing the stack limit. That's fine, because we only
deopt optimized frames one at a time. Other (non-topmost) frames are
only deoptimized once they are returned to.

Drive-by: Print variable and total frame height in --trace-deopt.

Bug: v8:9534
Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63330}