[i3c] Open points in Controller timing parameter calculation

The Controller derives its default SCL timing parameters from the `ClkFreq` top-level parameter, in `i3c_timing_pkg` and `i3c_ctrl_req_gen`, and software may override any of them through the `CTRL_TIME_*` registers. `doc/theory_of_operation.md` and `doc/integration_notes.md` state that the IP supports IP clock frequencies from 50MHz to 1.5GHz inclusive.

This calculation is a recent addition and is not yet finalized. This issue collects the open points.

### 1. The SDA sampling point may not leave enough margin

`i3c_timing_pkg.sv:114-117` places the sampling point for read data at the mid-point of the SCL low interval (`tclh`). This may not leave enough margin once the Target's `tSCO` (up to 20ns, I3C Basic 1.2 Table 50) and the full delay chain of Figure 73 are accounted for. Note that `tSCO` excludes the output driver delay and is specified from the Target's point of view, so the Controller must additionally allow for its own SCL output and SDA input path delays. With a 40ns SCL low interval at around 100MHz, sampling at the mid-point leaves roughly 10ns for all of those delays, which looks too short.

Options raised: move the sampling point later (an `sclh:scls` ratio of 3:1 rather than 1:1), or sample on the rising edge of SCL, which would give the greatest margin. It may also turn out that the worst-case `tSCO` of 20ns cannot be accommodated simultaneously with full-rate SDR0 signaling.

### 2. The legacy I2C modes overflow well below the documented 1.5GHz ceiling

`tm_cycles()` (`i3c_timing_pkg.sv:52-61`) returns an 11-bit (`TmCycW+1`) half-cycle count, and the per-phase parameters are stored in 10 bits (`TmCycW`, `i3c_pkg.sv:397`). Both wrap silently, giving these ceilings:

| Mode | SCL period | `tm_cycles()` limit | `tcls`/`tclh` limit |
|---|---|---|---|
| I2C FM | 2500ns | ~409MHz | ~1089MHz |
| I2C FM+ | 1000ns | ~1024MHz | ~2844MHz |
| SDR4 | 500ns | ~2047MHz | ~4414MHz |

The SDR and HDR-DDR modes are therefore fine across the whole documented range, but I2C Fast Mode breaks above roughly 409MHz and Fast Mode Plus above roughly 1GHz. Beyond those points the results are badly wrong rather than merely imprecise: at 1.5GHz the calculation yields an FM+ SCL period of 317ns instead of 1000ns, and an FM period of 452ns instead of 2500ns, i.e. clocking a legacy I2C device several times faster than its rated speed.

Either the arithmetic and `TmCycW` need more headroom for the legacy I2C modes, or the supported frequency range should be documented per signaling mode.

### 3. The calculated values need checking at the intended target frequencies

~~`i3c_ctrl_req_gen.sv:359-363` retains commented-out `show_timing()` calls together with a TODO for this reason~~ Timing is reported by the improvised test bench now; some of the hardware-calculated values are suspected to be conservative by one cycle. The values should be checked, and ideally asserted, for each frequency the IP is intended to be deployed at.

### 4. The software overrides are untested

Every `CTRL_TIME_*` field selects the hardware-calculated default when it reads all-ones, which is also its reset value, so the software override path is entirely unexercised today.

### 5. `tm_params_t` and `i3c_ctrl_timing_t` should converge

~~`i3c_timing_pkg.sv:12-19` and `i3c_timing_pkg.sv:66-77` declare two structures with identical fields. The two are being walked towards each other and one should ultimately be removed.~~
The type name `tm_params_t` is now simply a shorter, local alias of `i3c_ctrl_timing_t` which travels between the Core & Transceiver.

### 6. Decide whether one or more fields (such as `CTRL_TIME_OD.SCLHI_DIV2') should be renamed once the timing is proven.

### 7. Decide whether the signaling speed/mode for CmdArb/WaitAckb/SendAckb should be variable at all, e.g. configured bus type, target(s) addressed, non-initial bits being potentially faster.

Start by reading i3c_timing_pkg.sv, i3c_ctrl_req_gen.sv, and i3c_pkg.sv at the cited timing calculations and parameter definitions. Run the improvised timing test bench and inspect the CTRL_TIME_* handling; completion requires agreed timing behavior, verified values across intended frequencies, exercised overrides, and resolved naming or mode decisions.

Written by the indexing model from the issue text.