…Flight chunk that was rejected in the meantime (#36544)

`ensureSuspendableThenableStateDEV` patches `then` in fulfilled
thenables to avoid triggering a custom thenable's `then` in an
unexpected state. However, we weren't doing the same for rejected
thenables.

This affected `ReactPromise`, the type used for thenables passed from
server to client. if a `ReactPromise` passed to `use` was pending during
the render but became rejected between the abort and
`pushSuspendedCallSiteOnComponentStack`, then `ReactPromise#then` would
crash. (see the added test for a reprouction)
This is because we were putting the ReactPromise into an invalid state:
a `PendingChunk` expects to have a `value: null | Array<...>`, but we
were deleting `value` altogether, and tgus hitting `TypeError: can't
access property "push" of undefined` here:

https://github.com/facebook/react/blob/75b0945b18f4a60c80c931fd8067d9c715957879/packages/react-client/src/ReactFlightClient.js#L309
Bypassing the suspended thenable's `then` avoids this crash.

…#36328)

When a rejected `Promise` is instrumented in userspace while setting the
rejection reason in the wrong field (e.g. `error` instead of `reason`),
React will throw undefined (because `usable.reason` doesn't exist). This
makes it incredibly hard to find the actual rejection reason.

React is now throwing a generic error if we couldn't find the rejection
reason. That will produce a callstack pointing into the problematic
Promise from where you can hopefully extract the real rejection reason
(alongside fixing the bad instrumentation).

We're doing this in prod since this is unlikely to surface in dev. We're
only doing runtime type-checking for the rejected case. That should be
hit rarely and therefore hopefully have negligible runtime impact.