gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp

gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp

Bug PR gdb/33792 reported a gdb.server/fetch-exec-and-args.exp FAIL
when using the native-gdbserver board:

  FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file

The actual test output looks like this:

  (gdb) show remote exec-file
  The remote exec-file is unset, using automatic value "/tmp/build/gdb/testsuite/outputs/gdb.server/fetch-exec-and-args/fetch-exec-and-args".
  (gdb) FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file

This test actually fails with native-gdbsever and
native-extended-gdbserver boards.  The problem is that these boards
clear the sysroot.

This exact test has the following conditions:

  + The qExecAndArgs is in use (see 'packet=on').

  + We're not explicitly doing 'set remote exec-file ...' (see
    'set_remote_exec=false').

  + The test starts gdbserver without an executable (see
    'test_server_with_no_exec').

  + And because of the native-gdbsever board, the sysroot is "".

What this means is that GDB knows that gdbserver doesn't have an
executable thanks to qExecAndArgs, the user hasn't set an executable
for GDB to use when starting a new inferior, but GDB does know that
GDB and gdbserver can see the same filesystem due to the sysroot
setting.  GDB will then automatically use the current executable as
the remote executable name.  The test script doesn't expect this case,
and so the test fails.

Fix this by adjusting the script to expect the 'using automatic value
...' text when appropriate.

I also extended the test_server_with_no_exec proc to take a new flag
'clear_sysroot', we now run the test with the sysroot set to 'target:'
and with the sysroot set to "", even when using the 'unix' board.

Additionally, I ran the test through check-all-boards and found one
additional failure, when using --host_board=local-remote-host-native
and --target_board=local-remote-host-native.  In this case GDB copies
the executable to the remote host, which changes its filename.  When
the filename appears in the 'using automatic value ...' text, I was
expecting the filename assuming a local host.

I could fix this, but it doesn't seem worth the extra complexity for
this one test, so I've just set the test to be skipped for that one
configuration.

Now, when using check-all-boards, I'm seeing no failures.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33792

Approved-By: Simon Marchi <simon.marchi@efficios.com>