New formatter idea: worker-oriented view

Today, dots-v2 offers a great view of what is happening as tests execute. IMO, superior to others since it can show multiple packages making progress in parallel.

However, it only shows what Go's test output shows us, which misses a lot. Go has a lot of other diagnostic tools, most notably tracing and actiongraph (I talk a bit more about these [here](https://blog.howardjohn.info/posts/go-build-times/#tracing); there is no documentation in Go). These can be joined with the existing test data to give some pretty compelling visualizations, IMO.

Below is an example of a prototype I put together:

https://asciinema.org/a/DSUj5zSDHGG4XKKPp8rEy7Ycm

(note: its choppy as I turned down the write frequency to meet asciinema size limits)

Obviously the formatting is just a placeholder :slightly_smiling_face:. But we can see a much different than others would show us.

This currently shows a liner per thread, how many actions, how long the current action has lasted, and the action (with a number of completed tests, for test run actions). At the bottom, we also show the current and expected total amount of each action type (clearly, there is a bug here as we execute more than we expect :slightly_smiling_face: ).

Most notably, we can see that the actual execution of the tests accounts for a trivial amount of time - almost all time is spent on linking.

The three data sources provide:
* Actiongraph: gives us the execution plan, letting us know what packages are going to be built, tested, etc
* Trace: gives us the high level execution details. What is being executed on what thread.
* Test data: gives us details of a test execution.

Together I think these can provide an even richer experience than what is possible today.

I have a POC at https://github.com/howardjohn/gotestsum/tree/dotsv3. Its very hacky.

Start by comparing the existing dots-v2 formatter with the prototype in the dotsv3 branch. Review how actiongraph, trace, and test data are obtained and combined. The work is complete when a defined worker-oriented view integrates these data sources into a usable formatter rather than the current hacky POC.

Written by the indexing model from the issue text.