Check WorkerThread ownership before scheduling

[vasilmkd]

This covers the interleaving between two instances of WorkStealingThreadPool. I did not have a chance to test the performance impact thoroughly, but in the quick benchmark run I did, the new code was faster, which, I'm not sure whether to trust. I will repeat the run when I have the time.

series/3.x:

Benchmark                          (size)   Mode  Cnt   Score   Error    Units
WorkStealingBenchmark.scheduling  1000000  thrpt   10  13.270 ± 1.109  ops/min

This PR:

Benchmark                          (size)   Mode  Cnt   Score   Error    Units
WorkStealingBenchmark.scheduling  1000000  thrpt   10  13.981 ± 1.537  ops/min

[vasilmkd]

Here's another run:

series/3.x:

Benchmark                          (size)   Mode  Cnt   Score   Error    Units
WorkStealingBenchmark.scheduling  1000000  thrpt   20  15.228 ± 0.285  ops/min

This PR:

Benchmark                          (size)   Mode  Cnt   Score   Error    Units
WorkStealingBenchmark.scheduling  1000000  thrpt   20  14.966 ± 0.491  ops/min

[vasilmkd]

A new run of the scheduling benchmark:

Benchmark                          (size)   Mode  Cnt   Score   Error    Units
WorkStealingBenchmark.scheduling  1000000  thrpt   20  14.884 ± 0.635  ops/min

[vasilmkd]

Another run, but thermal throttling might have kicked in. The second fork was down in terms of the score.

Benchmark                          (size)   Mode  Cnt   Score   Error    Units
WorkStealingBenchmark.scheduling  1000000  thrpt   20  14.218 ± 0.894  ops/min