[Fizz] Refactor Component Stack Nodes (#30298)

Component stacks have a similar problem to the problem with keyPath
where we had to move it down and set it late right before recursing.
Currently we work around that by popping exactly one off when something
suspends. That doesn't work with the new server stacks being added which
are more than one. It also meant that we kept having add a single frame
that could be popped when there shouldn't need to be one.

Unlike keyPath component stacks has this weird property that once
something throws we might need the stack that was attempted for errors
or the previous stack if we're going to retry and just recreate it.

I've tried a few different approaches and I didn't like either but this
is the one that seems least problematic.

I first split out renderNodeDestructive into a retryNode helper. During
retries only retryNode is called. When we first discover a node, we pass
through renderNodeDestructive.

Instead of add a component stack frame deep inside renderNodeDestructive
after we've already refined a node, we now add it before in
renderNodeDestructive. That way it's only added once before being
attempted. This is similar to how Fiber works where in ChildFiber we
match the node once to create the instance and then later do we attempt
to actually render it and it's only the second part that's ever retried.

This unfortunately means that we now have to refine the node down to
element/lazy/thenables twice. To avoid refining the type too I move that
to be done lazily.

scripts/babel/transform-prevent-infinite-loops.js

@@ -13,7 +13,7 @@
 // This should be reasonable for all loops in the source.
 // Note that if the numbers are too large, the tests will take too long to fail
 // for this to be useful (each individual test case might hit an infinite loop).
-const MAX_SOURCE_ITERATIONS = 5000;
+const MAX_SOURCE_ITERATIONS = 6000;
 // Code in tests themselves is permitted to run longer.
 // For example, in the fuzz tester.
 const MAX_TEST_ITERATIONS = 5000;