Indicate the use of virtual time in withTimeout in TestScope

[dkhalanskyjb]

Fixes #3588

[qwwdfsad]

The overall idea with better diagnostic message is good, but I'm not sure that introducing our own additional extension is -- it breaks apart as soon as withTimeout is moved into a different method with effectively the same context, but without an explicit receiver.

Probably, a proper toString implementation appended to TimeoutCE will achieve the same result while being more robust. WDYT?

[dkhalanskyjb]

I wanted to do both because I didn't think it was reasonable to do something like

public interface Delay {
  val whatCanBeDoneToAvoidATimeout: String?

and just a message from withTimeout is not very actionable. The intention was for people to see that something test-module-related is wrong, try withTimeout in runTest itself in the debugging process, and then see the solution.

Though I guess if I manage to implement #3179 after all (it turned out to be very demanding) + an informative message in withTimeout, we will be able to rely on word of mouth to spread the correct solution to timeouts that have a specific test-module related message.

[qwwdfsad]

The reasoning works for me.

It seems like an alternative could be a slightly better Delay interface -- maybe it should be in control of both scheduling and timeout exceptions (e.g. to enhance stracktraces, add diagnostics to exceptions, provide domain-specific message etc.).
It should be achievable the moment we'll figure -Xjvm-defaults