Adds a failing test case where an update that was committed is
later skipped over during a rebase. This should never happen.

To enforce that updates that are committed can never be un-committed,
even during a rebase, we need to track which updates are part of the
rebase. The current implementation doesn't do this properly. It has a
hidden assumption that, when rebasing, the next `renderExpirationTime`
will represent a later expiration time that the original one. That's
usually true, but it's not *always* true: there could be another update
at even higher priority.

This requires two extra fields on the update queue. I really don't like
that the update queue logic has gotten even more complicated. It's
tempting to say that we should remove rebasing entirely, and that update
queues must always be updated at the same priority. But I'm hesitant to
jump to that conclusion — rebasing can be confusing in the edge cases,
but it's also convenient. Enforcing single-priority queues would really
hurt the ergonomics of useReducer, for example, where multiple values
are centralized in a single queue. It especially hurts the ergonomics
of classes, where there's only a single queue per class.

So it's something to think about, but I don't think "no more rebasing"
is an acceptable answer on its own.