[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le

[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le

On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit
step^M
28      { /* first-retry */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...

It's a bit easier to understand what happens if we do a full stepping session:
...
Temporary breakpoint 1, main ()
    at solib-intra-step-main.c:23
23        shlib_first ();
(gdb) step
shlib_first () at solib-intra-step-lib.c:29
29        shlib_second (0); /* first-hit */
(gdb) step
28      { /* first-retry */
(gdb) step
29        shlib_second (0); /* first-hit */
(gdb) step
shlib_second (dummy=0)
    at solib-intra-step-lib.c:23
23        abort (); /* second-hit */
...
and compare that to the line info:
...
CU: solib-intra-step-lib.c:
File name                    Line number    Starting address    View    Stmt
solib-intra-step-lib.c                22               0x710               x
solib-intra-step-lib.c                23               0x724               x
solib-intra-step-lib.c                28               0x740               x
solib-intra-step-lib.c                29               0x74c               x
solib-intra-step-lib.c                28               0x750               x
solib-intra-step-lib.c                29               0x758               x
solib-intra-step-lib.c                30               0x760               x
solib-intra-step-lib.c                 -               0x77c
...

So we step from line 29 to line 28, and back to line 29, which is behaviour
that matches the line table.  The peculiar order is due to using optimization.
The problem is that the test-case doesn't expect this order.

Fix this by allowing this order in the test-case.

Tested on powerpc64le-linux.

PR testsuite/29792
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29792