fixup single-step test

[SebKuzminsky]

This commit is an attempt to fix the test failure here: http://buildbot2.highlab.com/buildbot/#/builders/11/builds/990/steps/13/logs/stdio

I believe the test failure is due to a race condition in the test script, not a bug in LinuxCNC.

Before this commit, the test requests a step any time the machine X and Y positions are both very near an integer multiple of 5. The test failure linked above shows this in the log:

Taking step from X30.00 Y30.00
line=9; Xpos=30.98; Ypos=30.00; Zpos=0.00; counter=25
line=9; Xpos=31.82; Ypos=30.00; Zpos=0.00; counter=25
line=9; Xpos=32.65; Ypos=30.00; Zpos=0.00; counter=25
line=9; Xpos=33.48; Ypos=30.00; Zpos=0.00; counter=25
line=9; Xpos=34.32; Ypos=30.00; Zpos=0.00; counter=25
task: main loop took 0.015550 seconds
Taking step from X35.00 Y30.00
line=9; Xpos=35.00; Ypos=30.00; Zpos=0.00; counter=25
Taking step from X35.00 Y30.00
line=0; Xpos=35.00; Ypos=30.00; Zpos=0.00; counter=25
Taking step from X35.00 Y30.00
line=9; Xpos=35.00; Ypos=30.00; Zpos=0.00; counter=25
Taking step from X35.00 Y30.00
line=5; Xpos=34.02; Ypos=30.00; Zpos=0.00; counter=0
line=5; Xpos=33.19; Ypos=30.00; Zpos=0.00; counter=0
...
End counter incorrect:  5 != 25

Normally the test would stop at (X=35, Y=30) with counter=25, and the test would pass.

I believe in this case the test script got to run a couple of extra loops while waiting for LinuxCNC (Task & Motion) to respond to the earlier single-step requests, and thus queued up a bunch of extra single-step requests, which restarted the G-code program being single-stepped.

The G-code program starts out by resetting the counter, so when the test finished it saw the new counter from the (incorrect) next run of the G-code program.

This commit changes the test program to avoid this race, by waiting for each step to start and complete before considering issuing another step.