v0.2.0

The live tree costs a fraction of what it did on steps of tens of
thousands of targets. It handles every event and draws every frame under
a lock that the Bus waits for, and every worker that reports an event
waits for the Bus, so on such steps the tree slowed the work itself.

Changes a program or its tests may notice

progress/display:

• The live tree folds a set of more than 256 targets again at most once a
  second, rather than at every frame, so such a row may leave out the
  targets that ended in the last second. The count in the step's row, and
  the line a step leaves when it ends, stay exact. A test that draws
  frames less than a second apart over more than 256 targets sees the
  earlier fold (decision 16). This changes the text the tree draws, so the
  minor version goes up.

Faster

On one machine, best of three runs:

	v0.1.0	v0.2.0
Ending 16,000 targets	489 ms	98 ms
A run that draws a frame every 100 events, 16,000 targets	1.64 s	0.29 s
The same, 30,000 targets	6.0 s	0.83 s
A frame while 16,000 targets run	5.8 ms	0.72 ms
A frame while targets end, after 16,000 ended well	3.8 ms	13 µs

• A target that ends leaves its step in constant time, rather than with a
  pass over the step's other targets.
• A failure finds its row by its text, and a batch that ends adds its
  targets to its step's in place rather than copying the step's set.
• A frame builds only the rows of a list that fit the region, rather than
  one for every running target.
• The tree counts each event once, rather than a second time for the
  counter line it draws on a terminal too small for it.

The Go API, the counter, the plain lines and the event log are unchanged.