Thread tracking

Most IO programs are naturally asynchronous, so it is generally the case that a fiber can be bound to many potentially several different threads throughout its lifetime. Additionally, since users have control of the thread pool that fibers run on (i.e. async in CE2, shift), it's very easy to end up hogging a thread pool that shouldn't be. As part of the tracing feature set, we should offer users a way to easily observe what thread(s) a fiber has been bound to during its execution. Include that information in the trace buffer that already holds stack traces, and render them accordingly.

A fiber can only switch threads is at an asynchronous boundary, so we really just need to call Thread.currentThread() after
one is encountered and push that information to the IOEvent trace buffer. This behavior should be configurable. If it's not enabled, there should be negligible performance impact (similar to the stack tracing system property).

Start by tracing the existing stack-trace trace buffer and IOEvent handling around asynchronous boundaries. Determine how Thread.currentThread() data should be stored and rendered, then verify that the behavior is configurable and has negligible impact when disabled.