Solidify addTransitionType Semantics (#32797)
Stacked on #32793. This is meant to model the intended semantics of `addTransitionType` better. The previous hack just consumed all transition types when any root committed so it could steal them from other roots. Really each root should get its own set. Really each transition lane should get its own set. We can't implement the full ideal semantics yet because 1) we currently entangle transition lanes 2) we lack `AsyncContext` on the client so for async actions we can't associate a `addTransitionType` call to a specific `startTransition`. This starts by modeling Transition Types to be stored on the Transition instance. Conceptually they belong to the Transition instance of that `startTransition` they belong to. That instance is otherwise mostly just used for Transition Tracing but it makes sense that those would be able to be passed the Transition Types for that specific instance. Nested `startTransition` need to get entangled. So that this `addTransitionType` can be associated with the `setState`: ```js startTransition(() => { startTransition(() => { addTransitionType(...) }); setState(...); }); ``` Ideally we'd probably just use the same Transition instance itself since these are conceptually all part of one entangled one. But transition tracing uses multiple names and start times. Unclear what we want to do with that. So I kept separate instances but shared `types` set. Next I collect the types added during a `startTransition` to any root scheduled with a Transition. This should really be collected one set per Transition lane in a `LaneMap`. In fact, the information would already be there if Transition Tracing was always enabled because it tracks all Transition instances per lane. For now I just keep track of one set for all Transition lanes. Maybe we should only add it if a `setState` was done on this root in this particular `startTransition` call rather having already scheduled any Transition earlier. While async transitions are entangled, we don't know if there will be a startTransition+setState on a new root in the future. Therefore, we collect all transition types while this is happening and if a new root gets startTransition+setState they get added to that root. ```js startTransition(async () => { addTransitionType(...) await ...; setState(...); }); ```