Add the contract to runBlocking for shared JVM/Native code

[dkhalanskyjb]

Additionally, on Native, make thread keepalive checks a bit more efficient.

[dkhalanskyjb]

7 tests failed on the CI. Usually, that's pretty conclusive, but I fail to reproduce any of the failures on my machine. What's especially mysterious is that the tests failed on the JVM, where I don't think I did anything but 1) refactor the code somewhat and 2) remove the @Throws(InterruptedException) annotation.

[dkhalanskyjb]

I couldn't reproduce the issue locally after running a clean build in a loop for six hours (after which the Gradle daemon failed with an OOM, which is fun, but probably unrelated). Restarting the build on the CI, I don't observe the failure for the second time. Still, please review this especially carefully, because something did go wrong, and I have no idea what did.

The failures:

• A couple of println calls in the most mysterious place:

  at java.base/java.io.PrintStream.println(PrintStream.java:882)
  at org.openjdk.jol.vm.VM.current(VM.java:73)
  at org.openjdk.jol.layouters.CurrentLayouter.layout(CurrentLayouter.java:52)
  at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:72)
  at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:56)
  at kotlinx.coroutines.MemoryFootprintTest.assertLayout(MemoryFootprintTest.kt:34)

• A couple of println calls in TestBase.println. So, previousOut was set incorrectly, which is indeed possible if a test has finished without calling finish! Here's a fix for that and some other build failures: Improve test robustness #4369. It also makes it easier to understand what the mysterious println call was trying to tell us.
• A couple of threads had the wrong name?

[dkhalanskyjb]

runBlocking's @Throws on the JVM is important, as without it, some Java code breaks: https://grep.app/search?f.lang=Java&q=BuildersKt.runBlocking

[qwwdfsad]

A couple of println calls in the most mysterious place

Depending on the Java version, JOL from MemoryFootprintTest sometimes prints warnings to stderr/stdout. Maybe it's worth @Ignoreing it and using only as part of the development, as it requires non-trivial command-line args setup with modern Java

[qwwdfsad]

Consider using JUnit's assertFoo functions. Java's asserts can be disabled (or, to be more precise, can be not enabled). Especially for our custom Gradle setup, the simpler the thing -- the better

[qwwdfsad]

I would assume that it's possible to workaround the need for that middle layer by adding

@file:JvmMultifileClass
@file:JvmName("BuildersKt")

to Builders.concurrent.kt. Could you please consider doing so?