Count threads after thread-creation while still holding mutex lockrefs/pull/4365/head

The `Mutex` is locked with the `MutexLock` before spawning the thread, so that the thread is prevented from completing (by being blocked on `Mutex`) before the new thread count is obtained. However, the existing bug (introduced in 22e6055) releases `Mutex` before obtaining the new thread count, which allows the thread to run to completion in the meantime.

Also, since the `(thread_count_after_create != starting_count + 1)` condition (line 328) skips the remainder of the `for`-loop body on every iteration, `thread_count_after_join` stays uninitialized.

I believe this is why [this test failed][1] on the macOS CI with this trace:

```
[----------] 1 test from GetThreadCountTest
[ RUN      ] GetThreadCountTest.ReturnsCorrectValue
googletest/test/googletest-port-test.cc:350: Failure
Expected equality of these values:
  thread_count_after_create
    Which is: 1
  starting_count + 1
    Which is: 2

googletest/test/googletest-port-test.cc:351: Failure
Expected equality of these values:
  thread_count_after_join
    Which is: 140493185949400
  starting_count
    Which is: 1

[  FAILED  ] GetThreadCountTest.ReturnsCorrectValue (2 ms)
[----------] 1 test from GetThreadCountTest (2 ms total)
```

[1]: https://github.com/google/googletest/actions/runs/6064919420/job/16453860690?pr=3049

0 files changed, 0 insertions, 0 deletions