Support custom threads

[eupp]

No description provided.

[eupp]

The only failing CI configuration is "Integration Test with kotlinx.coroutines".
I believe it is because of #412, and once we merge #413 the problem should be fixed.
I've create a separate test branch where I merged the #413 into my branch, and it seems that there all kotlinx.coroutines tests are passed.

[eupp]

@ndkoval while working on this I discovered a few problems, which are probably should be addressed in separate PRs.

One of the problems is related to the local objects tracking --- the current implementation does not work correctly with custom threads (see example below and the comment in DataStructuresTests::incorrectHashMap test).
So the problem can be illustrated by the following example:

class Box(var x: Int)

fun test(): Int {
    val box = Box() // <- this object is incorrectly classified as a local object
    thread {
        box.x = 42 // the local object tracker does not detect here that the `box` object,
                   // stored in the local variable, escapes into another thread;
                   // thus it will not insert a switch point before accesses to this object fields
    }
    return box.x
}

I would propose that we can address this problem separately in another PR after we merge this one.
The reasons is that adding support of this case would require significant refactoring of local objects tracking algorithm,
and this PR is already big.

Alternatively, we can first perform the necessary refactoring of the local objects tracking algorithm in a separate PR,
and after this rebase and merge custom threads PR.

[eupp]

Another small bug fix on which this PR relies on: #426

[eupp]

From what I can see, there is no significant changes in the time of CI builds between this branch and develop:

• dynamic-threads branch
• develop branch

The reason is that in this PR I strive to preserve the old behavior whenever possible, by adding special treatment of TestThread class, see an example here:

lincheck/bootstrap/src/sun/nio/ch/lincheck/Injections.java

Line 91 in 3feb8a9

if (thread instanceof TestThread) {

Thus, all the code interacting with TestThread-s (i.e. threads created by Lincheck) should work almost the same as before, and there should be no new performance penalties for it.

[ndkoval]

How can this happen?

[eupp]

If I remember correctly, onThreadFinish is not guaranteed to be called at the end of the thread execution.
This can happen in case of timeout, or in case if some exception was thrown from the code and not properly handled.

To fix this, we will need to modify TestThreadExecutionGenerator class, to modify the generated bytecode. Wrap the code in try-catch, and put onThreadFinish into finally block to guarantee it is always called at the end.