Separate UDP GSO and GRO controls for Linux (--gso and --gro options)

# [Enhancement] Add independent control for UDP GSO and GRO (--gso, --gro)

## Problem Statement
Currently, `iperf3` supports UDP Generic Segmentation Offload (GSO) and Generic Receive Offload (GRO) via a single combined flag: `--gsro`. While this is convenient, it forces both offloads to be active simultaneously.

Testing shows that while GSO (sender-side) is almost universally beneficial, GRO (receiver-side) can cause significant CPU saturation on the receiver depending on the hardware and kernel version. Currently, there is no way to benefit from GSO without incurring the receiver-side overhead of GRO.

## Proposed Solution
I propose splitting the offload controls into two independent flags while maintaining backward compatibility:

1. `--gso`: Enables only `UDP_SEGMENT` on the sender.
2. `--gro`: Enables only `UDP_GRO` on the receiver.
3. `--gsro`: Remains as a legacy/convenience flag that enables both.

## Technical Motivation & Test Evidence
Testing across different Network Interface Cards (NICs) reveals that a "one-size-fits-all" approach to offloading is suboptimal.

### Test Environments
* **Env 1:** Intel X552 (10GbE) | Ubuntu 22.04 (Kernel 6.8)
* **Env 2:** Broadcom BCM57800 (10GbE) | Ubuntu 22.04 (Kernel 5.15)
* **Env 3:** Mellanox ConnectX-5 (25GbE+) | Ubuntu 24.04 (Kernel 6.17)

### Comparative Data
| Setup | Mode | Sender CPU | Receiver CPU | Notes |
| :--- | :--- | :--- | :--- | :--- |
| **Intel** | Baseline | 78.3% | 43.1% | |
| **Intel** | `--gsro` | 32.1% | **100.0%** | Receiver saturated by GRO |
| **Intel** | **`--gso`** | 32.0% | **41.4%** | Optimal efficiency |
| **Broadcom**| Baseline | 99.9% | 100.0% | 9.92 Gbps |
| **Broadcom**| `--gsro` | 70.6% | 99.5% | 9.92 Gbps |
| **Broadcom**| **`--gso`** | 72.1% | 98.6% | 9.92 Gbps (Stable) |
| **Mellanox**| Baseline | 99.8% | 76.8% | Bitrate stuck at 18.7G |
| **Mellanox**| `--gsro` | 66.0% | 99.8% | Bitrate reached 25G |
| **Mellanox**| **`--gso`** | 65.7% | **96.5%** | Bitrate reached 25G |

### Observations & Hardware Variance
* **The Intel Bottleneck:** On the X552, GRO is extremely "expensive," saturating the receiver CPU. Splitting the flags allows us to keep the 46% CPU saving on the sender (via GSO) without breaking the receiver.
* **The Broadcom Stability:** Unlike the Intel card, the Broadcom BCM57800 shows similar behavior whether using `--gsro` or `--gso`. While it doesn't suffer as much from GRO overhead, providing independent flags ensures consistent behavior across different testing toolsets.
* **The Mellanox Throughput:** On high-speed ConnectX-5 cards, GSO is the difference between hitting line rate (25G) or being CPU-bound at 18G. As with the Intel tests, using only GSO keeps the receiver from hitting the 100% ceiling.

**Conclusion:** Because different NIC models (Intel vs. Broadcom vs. Mellanox) handle offloads differently, users need granular control to avoid artificial bottlenecks during performance validation.

### Observations
* **GSO Efficiency:** In all environments, GSO drastically reduced sender CPU load or allowed for higher bitrates by offloading segmentation to the NIC.
* **GRO Bottleneck:** In Environment 1 and 3, GRO caused the receiver CPU to hit 100% saturation. Being able to disable GRO while keeping GSO active allows for higher performance tests without receiver-side bottlenecks.

## Implementation Details
The changes involve:
* Updating `iperf_api.h/c` to include the new boolean flags in the test settings.
* Modifying the logic in the UDP stream handlers to check for `--gso` or `--gro` specifically.
* Updating documentation in `iperf3.1` (man page).

## Use Cases
* Precise performance tuning for high-speed (10G/40G/100G) networks.
* Isolating kernel stack vs. hardware offload issues during debugging.
* Supporting environments where only the sender hardware supports offloading.