StreamInterceptor should/could use InheritableThreadLocal

[mikehearn]

As documented, JUnit loses stdout (and therefore log lines) when execution crosses into a new thread inside a test. This can be confusing because the printed text just disappears, which is unintuitive.

The stated rationale is that "it would be impossible to attribute [the output] to a specific test or container". Whilst there's no general way to do it:

• It would be better to just emit to stdout directly if it can't be properly captured rather than losing the printing.
• Using InheritableThreadLocal will handle the common case where code starts a thread as part of its work and then shuts the thread down, as that way the underlying RewindableByteArrayOutputStream will be propagated.

In theory (!) it's a simple enough change. As well as changing the TLS slot type, the RewindableByteArrayOutputStream needs to be made thread safe.

[elshad-faire]

We also recently realized that logs from different threads are not captured. I think there should at least be an option to enabled capturing from all threads or not. For our use case, it is ok if there will be logs from unrelated threads because it is more important to see the logs from relevant threads.

If JUnit team agrees to support capturing logs from all threads then I would be willing to contribute it.