work around wrong kernel type for sem_nsems member of struct semid_ds

rejecting invalid values for n is fine even in the case where a new
sem will not be created, since the kernel does its range checks on n
even in this case as well.

by default, the kernel will bound the limit well below USHRT_MAX
anyway, but it's presumably possible that an administrator could
override this limit and break things.

consistency: change all remaining syscalls to use SYS_ rather than __NR_ prefix

global cleanup to use the new syscall interface

initial check-in, version 0.5.0