Restructures the update queue to maintain a pointer to the first
pending update, which solves a few problems:

- Updates that occur during the begin phase (e.g. in cWRP of a child)
aren't dropped, like they are currently. This isn't working yet because
the work priority is reset during completion. The following item will
fix it.
- Sets us up to be able to add separate priorities to each update in
the queue. I'll add this in a subsequent commit.

This allows us to remove the hasCallback flag.

Removes another field from the update queue

When resetting the priority in the complete phase, check the priority of
the update queue so that updates aren't dropped.

Updates inside render, child cWRP, etc are no longer dropped.

The next step is sort the queue by priority and only flush updates that
match the current priority level.

We need to be able to access both, and since the list uses forward
pointers, it makes more sense to point to the one that comes first.
Otherwise to get the last progressed update you have to start at the
beginning of the list.

The queue maintains a pointer to the last progressed update in the list.
Updates that come after that pointer are pending. The pointer is set to
the end of the list during reconciliation.

Pending updates are sorted by priority then insertion. Progressed
updates are sorted by the order in which they were applied during
reconciliation, which may not be by priority: if a component bails out
before the updates are committed, in the next render, the progressed
updates are applied in the same order that they were previously, even if
a higher priority update comes in.

Once a progressed update is flushed/committed, it's removed from
the queue.

This is needed to get the triangle demo working.

Instead clear updates on the work-in-progress during the begin phase.
Aborted updates are recovered by cloning from the current fiber.

This is the most common case, so we should avoid scanning the entire
list to get to the end.

The update is scheduled as if the current processing update has already
been processed; if it has the same or higher priority, it will be
flushed in the same batch.

We also print a warning.

setState inside render/cWRP should have the same priority as whatever
level is currently being reconciled.

We can just check if the deadline has expired.

...rather than changing it on every unit of work.

Infinity is a floating point value.

Go back to using a flag, instead. I removed it before because I thought
we might want to get rid of the top-level UpdateQueue type and put
the fields directly on the fiber, but since we're keeping UpdateQueue
we can put hasForceUpdate on there.