[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

As reported here
( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
number of test-cases fails with a remote target setup, for instance test-case
gdb.base/print-file-var.exp.

So, why don't we see these fails with our remote target boards in
gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?

The problem is that the target board uses the same machine and user for
both (by-definition-local) build and remote target, and when using absolute
pathnames to refer to files on build, we can access those files on target,
which in a real remote target setup wouldn't be the case: we'd have to
download them to target first, and then the filename would also be different.

For aforementioned test-case, this happens when the name of a shared library is
passed as absolute file name to gcc:
...
gcc ...  -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
  print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
...

Make these problems visible with remote-gdbserver-on-localhost.exp by
adding an option to specify a test account (still on the same machine)
using REMOTE_TARGET_USERNAME.

We make sure by restricting file permissions, that the test account cannot see
the build files on the $USER account, and that the $USER account cannot see
the target files on the test account.

And so we can reproduce the reported fails:
...
$ cd build/gdb
$ tc="gdb.base/print-file-var.exp"
$ tb="--target_board remote-gdbserver-on-localhost"
$ tbu="REMOTE_TARGET_USERNAME=remote-target"
$ make check RUNTESTFLAGS="$tb $tbu $tc"
   ...
FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
  version_id_main=0: continue to STOP marker
...

Tested on x86_64-linux.

Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>