Fix shmat() on Linux nanomips and x86

Fix shmat() on Linux nanomips and x86

On Linux, there are two variants of the direct shmctl syscall:
- sys_shmctl: always uses shmid64_ds, does not accept IPC_64
- sys_old_shmctl: uses shmid_ds or shmid64_ds depending on IPC_64

The following Linux ABIs have the sys_old_shmctl variant:
  alpha, arm, microblaze, mips n32/n64, xtensa

Other ABIs (and future ABIs) have the sys_shmctl variant, including ABIs
that only got sys_shmctl in Linux 5.1 (such as x86, mips o32, ppc,
s390x).

We incorrectly assume the sys_old_shmctl variant on nanomips and x86,
causing shmat() calls under valgrind to fail with EINVAL.

On x86, the issue was previously masked by the non-existence of
__NR_shmctl until a9fc7bceeb0b0 ("Update Linux x86 system call number
definitions") in 2019.

On mips o32, ppc, and s390x this issue is not visible as our headers do
not have __NR_shmctl for those ABIs (396 since Linux 5.1).

Fix the issue by correcting the preprocessor check in get_shm_size() to
only assume the old Linux sys_old_shmctl behavior on the specific
affected platforms.

Also, exclude the use of direct shmctl entirely on Linux x86, ppc,
mips o32, s390x in order to keep compatibility with pre-5.1 kernel
versions that did not yet have direct shmctl for those ABIs.
This currently only has actual effect on x86 as only it has __NR_shmctl
in our headers.

Fixes tests mremap4, mremap5, mremap6.

https://bugs.kde.org/show_bug.cgi?id=410743