Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp

Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp

Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
causes several Tcl errors to appear. For example,

(gdb)
ERROR: : spawn id exp20 not open
    while executing
"expect {
-i exp11 -timeout 10
                -i "$inferior_spawn_id"
                -re ".*Cannot exec.*Permission denied" {
                    set saw_perm_error 1
                    verbose -log "saw..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp20 not open
UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)

This is happening because of the way this test is implemented:

        while {1} {
            gdb_expect {
                -i "$inferior_spawn_id"
                -re ".*Cannot exec.*Permission denied" {
                    set saw_perm_error 1
                    verbose -log "saw mi error"
                }
                -i "$gdb_spawn_id"
                -re "\\^error,msg=\"During startup program exited with code 127" {
                    set saw_mi_error 1
                    verbose -log "saw mi error"
                }
               # and so on
            }
        }

The first time this loop is executed, `inferior_spawn_id' is valid. When the
first branch of the expect statement is reached, gdbserver has exited, closing
the spawn_id.  Since we haven't seen the gdb-side error yet, the loop is executed
again.  The first branch now refers to a non-existent spawn_id, leading to the error.

This can be fixed by using exp_continue to loop in expect instead of looping around
expect, which is the approach I have used[1].  Note I've had to update the expected
message for the "During startup..." error message when running with gdbserver.

One other small change I've made is to add a log entry which spills the values of
the two variables, saw_mi_error and saw_perm_error (and updated the log output
for the later).  This should make the log output clearer about why the test failed.

With this patch installed, all the ERRORs disappear, leaving previously masked
FAILs (which I have not attempted to fix).

[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
assume that it was intentionally written this way, and I've modified the code with
that assumption. I have tested a version using gdb_test_multiple, and that appears
to work fine, too, if that is preferred. [It still employs exp_continue to fix the
spawn_id errors.]