Port IPC::SysV (low priority)

The issue requires porting the IPC::SysV module to PerlOnJava using Java's FFM/native access. Start by examining the existing bytecode backend operation slots and compiler/interpreter scaffolding for semaphore, message-queue, and shared-memory operations, which currently throw UnsupportedOperationException. Review the Perl IPC::SysV module's API and the Java FFM documentation. Implement the constants, ftok, and the three IPC mechanisms (semaphores, shared memory, message queues) with proper error handling and cleanup. Write focused tests for each operation and validate with a dependent module like IPC::Pleather or IPC::Transit.

Summary

Port IPC::SysV to PerlOnJava using Java FFM/native access on Unix platforms.

This is a low-priority ecosystem-enablement task. The current targeted
MetaCPAN lookup found 14 released runtime dependants, including
IPC::Pleather, IPC::Transit, IPC-Shm-Simple, SysV-SharedMem, and
Proc-Swarm; 2 were recent dependants. Recheck this count before prioritizing
implementation, and increase priority if the dependant population grows.

Scope

• Provide the IPC::SysV constants and ftok behavior.
• Implement System V semaphores: semget, semop, semctl, and the
  IPC::Semaphore support they require.
• Implement shared memory: shmget, shmat, shmdt, shmctl, memread,
  and memwrite.
• Implement message queues: msgget, msgsnd, msgrcv, and msgctl.
• Preserve Perl-visible return values, errno/error behavior, cleanup, and
  concurrency semantics.
• Define platform behavior explicitly: native Unix support first; Windows
  should either use a real compatible implementation or fail clearly if SysV
  IPC is unavailable.

Existing groundwork

The bytecode backend already has operation slots and compiler/interpreter
scaffolding for semaphore, message-queue, and shared-memory operations, but
the handlers currently throw UnsupportedOperationException.

Acceptance criteria

• Focused project-owned tests cover constants, semaphore operations, shared
  memory, message queues, errors, cleanup, and cross-process visibility where
  supported.
• Tests pass on both JVM and interpreter backends where applicable.
• At least one dependent module is validated after the port.
• Documentation records supported platforms and limitations.

Related: #1144 (pseudofork support may remain a separate requirement for
modules that depend on fork).