Fold what DCE does into FIND-DFO.

Fold what DCE does into FIND-DFO.

DCE was essentially FIND-DFO with a stricter definition of reachable
for entry points. So we were doing a lot of repeated graph walking. We
can just make FIND-DFO use the definition of entry point reachability
that eliminate-dead-code used to achieve the same effect. This has a
number of speed advantages:

* We don't need to walk every node in the graph: FIND-DFO works with
just basic blocks.

* The graph isn't walked at all when nothing in the DFO has changed.

* The entry points are now also forced to be "sorted": entry points
which are only accessible from other entry points have lower DFNs,
which means that intraprocedural things like type propagation through
local calls might converge faster when iterating in DF order.

There is one potential performance caveat though: We take advantage of
the fact that FIND-DFO does iteration to properly compute the set of
reached entry points. However, this may in the worst case cause a
linear number of iterations to fixpoint with respect to the maximum
entry point nesting depth (an entry point being nested if its only
accessible from another entry point), so a quadratic number of total
iterations over the component's lambdas in terms of this nesting
depth. This doesn't happen in practice, probably because nested
lambdas sorted in the worst possible way just doesn't happen due to
the way IR is converted. When instrumenting self-build, it's actually
the case that the top-level DO in FIND-DFO does either the same or
one *less* iteration (probably due to dead :OPTIONAL entries) when
checking for entry point reachability. So finding new blocks in the
component seems to overshadow any theoretical worst-case lambda
nesting concerns.