Make sure we resume on progressed hidden children. I split these out
into their own functions so that it doesn't distract from the normal,
non-hidden code path. Will also make it easier to reuse later if/when
we apply the offscreen children feature to other types of components.

There was some unnecessary abstraction in ReactFiberClassComponent that
was making it difficult to maintain and, ironically, causing some
duplication. I've moved most of that module into the begin phase,
and consolidated the separate mount, resume mount, and update functions
into a single function that's easier to reason about.

A resume is where we continue working on an already existing work-in-
progress. A reset is where we create a new work-in-progress by cloning
values from current.

It's fine for the work-in-progress and current fiber to have the same
update queue, until we begin work on that fiber. At that point, we need
to clone the current queue to create a work-in-progress queue. Works
pretty much just like fibers.

I'd accidentally reversed which ones were passed to the method and
which ones were set on the instance. D'oh.

It's possible for a work-in-progress fiber to be the most progressed
work (last fiber whose children were reconciled) but be older than
the current fiber. This scenario, where the work-in-progress fiber
is really the "previous current," happens after a bailout. To avoid,
in addition to keeping track of the most progressed fiber, we also
keep track of the most recent fiber to enter the begin phase,
regardless of whether it bailed out. Then we only resume on the work-
in-progress if its the most recent fiber.

It'd be nice to come up with a heuristic here that didn't require an
additional fiber field.

Also, the naming of "progressedWork" versus "newestWork" is not great.
Maybe "lastUpdatedWork" and "lastUpdatedOrBailedOutWork"? We can
bikeshed later.

Helps ensure we don't accidentally reuse props from the current tree,
or from an invalid work-in-progress ("previous current").

The pendingWorkPriority should be reset, not the progressedPriority.

Only bubble work priority from the work-in-progress tree. Otherwise you
could fall into an infinite loop because the current tree's priority
is never reset.

However, update priority should always be bubbled up from the children,
even after a bailout, because there might be low priority updates.

When resetting a work-in-progress to current, if the progressed priority
is the render priority, then the progressed work must be invalid.
Otherwise we would have resumed instead of resetting. So don't stash it,
just throw it out.

There's only ever one progressed work object per fiber pair. Reuse the
same object every time instead of allocating. The first time a high-
priority update interrupts a low one, we'll still have to allocate a
ProgressedWork object per fiber. But not for subsequent interruptions.

...unless there was already an update scheduled. Need to compare the
memoized props to current, not the next props.

TODO: this will fail if we bailout with shouldComponentUpdate twice
before committing, because the props and state are updated after the
first bailout. Only observable in async mode. Need to find a better
heuristic. We can't read from the effectTag because it may have been
reset during reconciliation.

Don't bubble up priority inside deprioritized trees.

Also, throw an error if an element with a string ref does not have an
error. Fiber was throwing, but not until the commit phase, and with
a bad error message.

Mistake caused by poor naming. Renamed priorityLevel -> minPriorityLevel
to avoid confusion with nextPriorityLevel.

This lets us reuse the logic in transferEffectsToParent. Requires adding
two fields to the FiberRoot type, but I figure those are
fairly inexpensive. Otherwise I'll revert and duplicate that
code, instead.

Don't know why this stopped working. Is it related to bundling? If so, I
wouldn't expect it to happen in a Jest environment.

Take another look at this before landing.

Missed this one.

...in case the lifecycles contain updates

We can reuse it for coroutines, which reconcile children stored on
the stateNode.

Pretty much anything that isn't component-specific can be moved out.
Then we can reuse them in the complete phase.

I would expect that whenever we resume on progressed work, the child
set is a work-in-progress set.

Without this guard, the function throws

...rather than in reconcile and begin. Easier to keep track of.

Progressed priority could be less than work priority if there's a
setState deep in the tree that's less than the current render priority
but greater than the priority at which the fiber last reconciled.

ProgressedWork is a subset of Fiber. We use a separate Flow type to
prevent access of extra properties, but we use a whole Fiber for
monomorphism.

I had this wrong in an earlier commit. Performing work in the
work-in-progress tree should never add work to the current tree. Only
state updates do. So in the complete phase, we should bubble priority
up from the children even if they are current, so that we don't drop
pending updates.

Also realized there's no reason to check if a work-in-progress is
valid during a bailout. By the time we get to that function, we already
determined if the work-in-progress is valid during the
resume-or-reset step.

New test suite simulates the triangle demo. It renders a recursive
tree and flushes it unit by unit, resetting the unit of work pointer
to the root after each triangle is rendered. It also simulates the hover
effect by updating a target node with high priority.

The test is written in such a way that we can add fuzz testing on top
of it later. For now, I've "manually" fuzz tested by trying out
arbitrary values.

Makes bugs more noticeable.

Avoided doing this originally because I didn't want to add a field to
the fork, and figured we could infer this in other ways. But the fork
is a full Fiber for monomorphism purposes, anyway, so we already
have it.

This allows for multiple nodes to be active at a time, which isn't
possible in the demo because to hover over on node you must leave
the other.

Most incremental tests rely on yielding at a specific point. Using an
explicit API, rather than relying on fake expiration times that rely
on implementation details, should make our tests more resilient and
reduce false positives.

If `insertAfter` is null, the insertion position is at the start of the
list. Similarly, if the `insertBefore` is null, the insertion position
is at the end of the list.

The starting/end position of one list is not necessarily the same as the
starting/end position of another. So, only compare non-null values.

Previous version couldn't increment the counter more than once before
flushing, which meant it couldn't reproduce certain errors that occur
when running the triangle demo in Firefox, where starvation is worse.

The new version uses a Redux-like approach, with actions.

This actually wasn't causing an error because the arguments were
flipped twice: the first time to the wrong order, and the second time
back to the correct order :D

This bug illustrates that our `progressedPriority` model is wrong. When
deciding whether to resume work, we should compare the priority at which
the parent reconciled its children, not the priority at which the fiber
itself reconciled.