Intermediate value tracing

When we run an IO program, we can usually only look at the immediate output of that program without much visibility into what actually happened during execution, i.e. IO is a blackbox. Asynchronous stack tracing makes some progress in closing this gap in visibility by illustrating the code paths that a program takes. However, this doesn't really tell us why a program took some particular code path, and it doesn't really tell you why the result of a program is what it is in general. We can help out by logging the values we encounter in the program tree and rendering them later as part of the fiber trace.

The solution I've come up with is to take look at the value in the run-loop whenever hasUnboxed is equal to true and push it to the trace buffer. We obviously can't look at local variables inside a closure, so the amount of information that a user gets will be bounded by how frequently they drop into IO. @djspiewak had some thoughts about how we should capture values in a review comment. We'll have to think about how we can coalesce these values with the other events when rendering.

As usual, there should be negligible performance impact with merging this feature in.

Start by examining the IO run-loop, especially the hasUnboxed path, along with the trace buffer and fiber-trace rendering mentioned in the issue. Review the linked discussion about capturing values and determine how values could be coalesced with existing events. Done means the design, rendering behavior, and negligible performance impact are validated.