[tlul,dv] Checking "change without accept" behaviour

### Description

The TileLink spec allows a sender to change address or data "unilaterally" if the receiver doesn't signal READY. In the TileLink specification, version 1.8.1, this is described in detail in "4. Serialization" (page 19).

This behaviour is actually tracked in our coverage: `tlul_assert.sv` defines sequences like this:
```systemverilog
// a_valid is dropped without a_ready
sequence aValidNotAccepted_S;
h2d.a_valid && !d2h.a_ready ##1 !h2d.a_valid;
endsequence
```

But these aren't seen in our coverage reports because we don't actually do this in our DV!

An easy way to see it happen might be to define a container class that holds a set of TL items, which are allowed to be applied in any order. Then a driver acting as a sender can work by trying the first one. If the receiver doesn't assert READY on that cycle, the driver can switch to another unsent item for the second cycle (and so on).

We still won't see the coverage items being hit when a receiver always asserts e.g. `a_ready`. In that situation, we might choose to use a waiver file, or maybe add a parameter to `tlul_assert` so that we don't generate that `cover` point (but do assert that READY is always true) in that case.

Start with tlul_assert.sv and the existing TileLink DV coverage and driver code. Trace how A-channel items are generated and accepted, then determine how to exercise changing an unsent item when READY is low. Done means the relevant coverage is hit in DV, with the always-ready case handled as described in the issue.

Written by the indexing model from the issue text.