seccomp: accept syscall group names in both --extra-deny-syscall and --extra-allow-syscall

[congwang-mk]

--extra-deny-syscall and --extra-allow-syscall treated group names asymmetrically, and the allow side failed silently:

• deny accepted only individual syscall names, so denying SysV IPC took four flags naming each member syscall;
• allow accepted group names but validated nothing: a typo (--extra-allow-syscall sysvipc) built a sandbox that silently kept the group blocked, and the existing unit test even asserted that no-op.

Both flags now resolve names through a shared SYSCALL_GROUPS table (currently just sysv_ipc):

• --extra-deny-syscall accepts a syscall name or a group name; groups expand to their member syscalls in resolve_blocklist, for both the supervised and no-supervisor blocklists.
• --extra-allow-syscall accepts group names only; unknown names are rejected with the known-group list in the error. Individual syscalls stay non-re-allowable on purpose: punching single-syscall holes in the default blocklist can bypass the mediation boundary (io_uring being the canonical example).
• Allow/deny conflicts fail at build time: the same group on both sides, or a deny of a member syscall of an allowed group. The check has to be up front because the BPF layout places notif JEQs before deny JEQs, so an allowed group routing a syscall to notif would silently shadow a kernel-level deny of that same syscall.

Docs updated (sandbox-reference.md, python README). New unit tests cover group expansion in both blocklists, unknown-name rejection on both flags, rejection of individual syscall names on the allow side, and both conflict shapes.