[Synchronous Suspense] Don't delete children of suspended component

[acdlite]

Vestigial behavior that should have been removed in #13823.

Found using the Suspense fuzz tester in #14147.

[sebmarkbage]

Why do you think we didn't catch this in the code or the simple tests we added?

Have we hit terminal complexity?

[sizebot]

Details of bundled changes.

Comparing: 3d8bda7...c41126f

scheduler

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
scheduler.development.js	n/a	n/a	0 B	19.17 KB	0 B	5.74 KB	UMD_DEV
scheduler.production.min.js	n/a	n/a	0 B	3.16 KB	0 B	1.53 KB	UMD_PROD

Generated by 🚫 dangerJS

[acdlite]

@sebmarkbage I blame it on sloppiness on my part when I was updating the tests in #13823. But yeah, it's getting pretty complex, too.

There are a few things in our Suspense implementation that are unusual:

• Custom reconciliation. We conditionally wrap the children in a fragment while preserving their state.
• Outside concurrent mode, we commit the suspended tree in an incomplete state. By itself, this is similar to our hidden trick.
• Semantic divergence between concurrent and synchronous mode. Usually the only difference between the two modes is scheduling. There are some second order things that diverge, but synchronous mode is essentially a subset of the semantics of concurrent mode. But with Suspense, the semantics are forked.
• Hiding a tree instead of deleting it. Conceptually similar to the hidden trick except we have to do the hiding ourselves, by toggling the nearest host children.

Any one of these quirks by themselves isn't so complex, but we have to consider all of them together.

I still think they're worth it, but if we ever decide it's too much, we might need to drop one of these constraints.