Update ReactDebugInfo types to declare timing info separately (#31714)

This clarifies a few things by ensuring that there is always at least one required field. This can be used to refine the object to one of the specific types. However, it's probably just a matter of time until we make this tagged unions instead. E.g. it would be nice to rename the `name` field `ReactComponentInfo` to `type` and tag it with the React Element symbol because then it's just the same as a React Element. I also extract a time field. The idea is that this will advance (or rewind) the time to the new timestamp and then anything below would be defined as happening within that time stamp. E.g. to model the start and end for a server component you'd do something like: ``` [ {time: 123}, {name: 'Component', ... }, {time: 124}, ] ``` The reason this needs to be in the `ReactDebugInfo` is so that timing information from one environment gets transferred into the next environment. It lets you take a Promise from one world and transfer it into another world and its timing information is preserved without everything else being preserved. I've gone back and forth on if this should be part of each other Info object like `ReactComponentInfo` but since those can be deduped and can change formats (e.g. this should really just be a React Element) it's better to store this separately. The time format is relative to a `timeOrigin` which is the current environment's `timeOrigin`. When it's serialized between environments this needs to be considered. Emitting these timings is not yet implemented in this PR. --------- Co-authored-by: eps1lon <sebastian.silbermann@vercel.com>