gdb/testsuite: update test gdb.base/step-over-syscall.exp

gdb/testsuite: update test gdb.base/step-over-syscall.exp

I was looking at PR gdb/19675 and the related test
gdb.base/step-over-syscall.exp.  This test includes a call to kfail
when we are testing a displaced step over a clone syscall.

While looking at the test I removed the call to kfail and ran the
test, and was surprised that the test passed.

I ran the test a few times and it does sometimes fail, but mostly it
passed fine.

PR gdb/19675 describes how, when we displaced step over a clone, the
new thread is created with a $pc in the displaced step buffer.  GDB
then fails to "fix" this $pc (for the new thread), and the thread will
be set running with its current $pc value.  This means that the new
thread will just start executing from whatever happens to be after the
displaced stepping buffer.

In the original PR gdb/19675 bug report Yao Qi was seeing the new
thread cause a segfault, the problem is, what actually happens is
totally undefined.

On my machine, I'm seeing the new thread reenter main, it then starts
trying to run the test again (in the new thread).  This just happens
to be safe enough (in this simple test) that most of the time the
inferior doesn't crash.

In this commit I try to make the test slightly more likely to fail by
doing a couple of things.

First, I added a static variable to main, this is set true when the
first thread enters main, if a second thread ever enters main then I
force an abort.

Second, when the test is finishing I want to ensure that the new
threads have had a chance to do "something bad" if they are going to.
So I added a global counter, as each thread starts successfully it
decrements the counter.  The main thread does not proceed to the final
marker function (where GDB has placed a breakpoint) until all threads
have started successfully.  This means that if the newly created
thread doesn't successfully enter clone_fn then the counter will never
reach zero and the test will timeout.

With these two changes my hope is that the test should fail more
reliably, and so, I have also changed the test to call setup_kfail
before the specific steps that we expect to misbehave instead of just
calling kfail and skipping parts of the test completely.  The benefit
of this is that if/when we fix GDB this test will start to KPASS and
we'll know to update this test to remove the setup_kfail call.