Support concurrent uplink/downlink responsiveness mode (draft §5.1.2)

## Motivation

`mach rpm` currently measures downlink and uplink responsiveness sequentially: it runs the download leg first and then the upload leg, producing separate RPM results for each direction.

[draft-ietf-ippm-responsiveness-09 §5.1.2](https://datatracker.ietf.org/doc/html/draft-ietf-ippm-responsiveness-09#section-5.1.2) ("Concurrent vs Sequential Uplink and Downlink") also describes the concurrent case, where uplink and downlink are exercised at the same time and an overall responsiveness result is reported.

Would it make sense for `mach rpm` to expose the concurrent variant as an optional mode as well, while preserving the current sequential behavior?

## Existing pieces

There already seems to be useful infrastructure for this in the project:

- `mach rpm` implements responsiveness measurement under load, but currently runs the downlink and uplink legs sequentially.
- `mach saturate both` already runs downlink and uplink load generation concurrently.
- `mach saturate` reuses `Responsiveness` with `determine_load_only: true`, disabling responsiveness probes while retaining the load/capacity machinery.

PR #33, which introduced `mach saturate`, describes the implementation as a small modification of the existing responsiveness test:
https://github.com/cloudflare/networkquality-rs/pull/33

A proper concurrent responsiveness mode would appear to require more than simply enabling RPM independently on both `Responsiveness` instances.

Two independent instances currently have independent probe streams, RPM aggregation, stabilization and termination. One direction could therefore finish and stop generating load while the other is still measuring, which would no longer represent bidirectional working conditions.

It seems that the concurrent variant would instead need coordinated uplink/downlink load generation with jointly aggregated responsiveness measurements, producing the overall result described by §5.1.2.

Conceptually, the CLI could be something like:

```text
mach rpm --mode sequential # current behavior
mach rpm --mode concurrent # uplink + downlink simultaneously
```

The exact interface and internal design are of course open to discussion. Keeping sequential as the default would preserve compatibility and remains useful for identifying which direction is responsible for poor responsiveness.

Would supporting the concurrent variant fit the intended scope of `networkquality-rs`?

If so, I'd be interested in working on an implementation.

Start with the mach rpm responsiveness flow and compare it with mach saturate both and the Responsiveness machinery described in the issue. Determine how concurrent load generation, probe coordination, aggregation, stabilization, and termination should produce the overall result from draft §5.1.2 while preserving sequential mode as the default.

Written by the indexing model from the issue text.