Refactor: Switch from Multi-Threaded to Multi-Process Model for All IPC Mechanisms

[dustinblack]

The current benchmark suite is implemented using Tokio tasks that run within a single process. This setup
measures Inter-Thread Communication (ITC), which has fundamentally different performance characteristics from
the Inter-Process Communication (IPC) that the benchmark is intended to measure. This applies to all mechanisms
currently tested (UDS, SHM, TCP, and PMQ).

This architectural choice prevents a valid performance comparison against standard IPC benchmarks, which almost
universally use separate processes. To ensure the benchmark is correct and the results are valid, we must switch
from a threaded model to a true multi-process model for all tested mechanisms.

Proposed Solution

The BenchmarkRunner should be refactored to use the fork() system call to create a child process for all IPC
tests.

• The parent process will take on the role of the message sender (the "client").
• The child process will take on the role of the message receiver (the "server").

This change will ensure that we are measuring the performance of communication across distinct process
boundaries, which is the correct methodology for an IPC benchmark. The nix crate, which is already a
dependency, provides a safe and idiomatic wrapper for the fork() syscall and should be used for the
implementation.

Acceptance Criteria

• The BenchmarkRunner's execution path for all IPC mechanisms is modified to use fork() to create a child
  process.
• The parent process is configured to act as the message sender for all tests.
• The child process is configured to act as the message receiver for all tests.
• The parent process correctly waits for the child process to exit and handles its exit status.
• Existing process-specific configurations, such as --server-affinity and --client-affinity, are correctly
  applied to the child and parent processes, respectively.
• All benchmarks (UDS, SHM, TCP, PMQ) run to completion in the new multi-process configuration without
  errors.

Context

This is the highest priority task (P0) required to validate the rusty-comms benchmark suite. It is a
foundational prerequisite for other critical changes, such as implementing correct end-to-end latency
measurement, and it correctly aligns the entire suite with standard IPC testing methodologies.