Revert of "[heap] Clean up stale store buffer entries for aborted pages." (patchset #3 id:40001 of https://codereview.chromium.org/1494503004/ )

Reason for revert:
Still failing on GC stress
  https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/690

Original issue's description:
> Reland of "[heap] Clean up stale store buffer entries for aborted pages."
>
> This reverts commit d4fc4a8c.
>
> 1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
> 2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
>     store buffer.
> 3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
> 4.  The current mark-sweep finishes. The slot X is in free space and is also in
>     the store buffer.
> 5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
>     looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
>     previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
>     object before.
> 6.  Scavenge happens.
> 7.  Slot X is still in free space and in store buffer. [It causes scavenge of
>     the object Y in
>     store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
>     it is not important].
> 8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
>     is written in X.
> 9.  The scavenge finishes.
> 9.  Another scavenge starts.
> 10. We crash in
>     store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
>     processing slot X, because it doesn't point to valid map.
>
> BUG=chromium:524425, chromium:564498
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/fc6ff534003480e49dc481d9c665e961ab709c02
> Cr-Commit-Position: refs/heads/master@{#32514}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498

Review URL: https://codereview.chromium.org/1492823002

Cr-Commit-Position: refs/heads/master@{#32520}