9p: newfstatat behaves differently than fstat causing ENOENT for here-documents
Description of problem:
After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error.
Steps to reproduce:
1. I have file `a` with:
```
cat <<EOF
x
EOF
```
2. User visible error inside VM:
```
root@x86_64:~# grep 9p /proc/mounts
/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0
root@x86_64:~# bash a
cat: -: No such file or directory
```
3. `strace -fyv bash a` shows:
```
  [pid   291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */,
st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0
  [pid   291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory)
  [pid   291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5
  [pid   291] write(2</dev/ttyS0>, "-", 1-) = 1
  [pid   291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27
  [pid   291] write(2</dev/ttyS0>, "\n", 1
```
Additional information:
In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows:
```
  [pid   283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204,
st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0
  [pid   283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */,
st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0
  [pid   283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
  [pid   283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000
  [pid   283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2
  [pid   283] write(1</dev/ttyS0>, "x\n", 2x
```

So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently.