DrSyscall: Improve Linux argument naming

[321Proteus]

Add a pointer to any prior users list discussion.
This DrMemory Users' Group Thread

Is your feature request related to a problem? Please describe.
I've been building a Linux-main tracer client, whose one of the task is logging syscalls using drsys_iterate_args() and noticed that drsys_arg_t.arg_name is always set to NULL for Linux syscalls. That's because syscall_info_t doesn't expose any parameter names.

Describe the solution you'd like
The most simple and self-documenting tweak would be to add an arg_name field to sysinfo_arg_t. This way, instead of writing "handle_xyz" for every syscall, arg names essentially become part of the docs:

// before
{{PACKNUM(86,9,9,-1),0},"link", OK, RLONG, 2,
 {
     {0,0, R|CT, CSTRING},
     {1,0, R|CT, CSTRING},
 }
}
// after
{{PACKNUM(86,9,9,-1),0},"link", OK, RLONG, 2,
 {
     {0,0, R|CT, CSTRING, .arg_name = "oldname"},
     {1,0, R|CT, CSTRING, .arg_name = "newname"},
 }
}

It can be also expanded by adding names for the previously omitted inlined scalars:

// before
{{PACKNUM(9,-1,-1,SYS_mmap),0},  "mmap",  OK, RLONG, 6,}
// after
{{PACKNUM(9,-1,-1,SYS_mmap),0},  "mmap",  OK, RLONG, 6,
{
 {0, sizeof(void*),  SYSARG_INLINED, DRSYS_TYPE_POINTER,     .arg_name = "addr"},
 {1, sizeof(size_t), SYSARG_INLINED, DRSYS_TYPE_SIZE_T,      .arg_name = "length"},
 {2, sizeof(int),    SYSARG_INLINED, DRSYS_TYPE_SIGNED_INT,  .arg_name = "prot"},
 {3, sizeof(int),    SYSARG_INLINED, DRSYS_TYPE_SIGNED_INT,  .arg_name = "flags"},
 {4, sizeof(int),    SYSARG_INLINED, DRSYS_TYPE_SIGNED_INT,  .arg_name = "fd"},
 {5, sizeof(off_t),  SYSARG_INLINED, DRSYS_TYPE_SIGNED_INT,  .arg_name = "offset"},
}

In fact, this scheme (just without names) is already present in the code - other OSes denote full argument ranges, they're also present in the IOCTL sub-table and sometimes in the main Linux table (see e.g. getrandom, rseq and syncfs).

Do you have any implementation in mind for this feature?
Yes, currently working on it at my fork.

Describe alternatives you've considered
Since this is an API update proposal, I'll leave this field empty.