As #15571 reports, eager blackholing breaks sanity checks as we can't
zero the payload when eagerly blackholing (because we'll be using the
payload after blackholing), but by the time we blackhole a previously
eagerly blackholed object (in `threadPaused()`) we don't have the
correct size information for the object (because the object's type
becomes BLACKHOLE when we eagerly blackhole it) so can't properly zero
the slop.

This problem can be solved for AP_STACK eager blackholing (which unlike
eager blackholing in general, is not optional) by zeroing the payload
after entering the stack. This patch implements this idea.

Fixes #15571.

Test Plan:
Previously concprog001 when compiled and run with sanity checks

    ghc-stage2 Mult.hs -debug -rtsopts
    ./Mult +RTS -DS

was failing with

    Mult: internal error: checkClosure: stack frame
        (GHC version 8.7.20180821 for x86_64_unknown_linux)
        Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

thic patch fixes this panic. The test still panics, but it runs for a while
before panicking (instead of directly panicking as before), and the new problem
seems unrelated:

    Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 296
        (GHC version 8.7.20180919 for x86_64_unknown_linux)
        Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

The new problem will be fixed in another diff.

I also tried slow validate (which requires D5164): this does not introduce any
new failures.

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15571

Differential Revision: https://phabricator.haskell.org/D5165