[tlul] How PutFullData vs PutPartialData should be used

Nobody has claimed this yet.

Tilelink has two separate write messages `PutFullData` and `PutPartialData`. When `PutFullData` is used every byte must be written as indicated by the `a_mask` field of the message payload, where the written bytes are a function of `a_size` and `a_address`.

For Ibex and the RISC-V debug module this presents a slight difficulty, they give no indication as to whether their write is full or partial. However this can be determined by looking at the byte-enables. The question is whether we want to bother with this logic?

It is perfectly permissible for `PutPartialData` to write every byte, `PutFullData` is really only an optimisation which is most useful in the TL-UH variation of the protocol which includes bursts. Here `PutFullData` allows an agent to know every byte is being written before it has seen every message of the burst. We don't have bursts in TL-UL so we don't have this reason to use `PutFullData`

On the other hand some agents may only wish to implement `PutFullData`, for example a device may decide it only wants full 32-bit accesses, from my reading of the Tilelink specification it would be permissible for such a device to return an error on any `PutPartialData` message or `PutFullData` message with a non 32-bit size.

One path forward would be to say the Ibex adapter (to keep it as simple as possible) only emits `PutPartialData` in which cases devices must be able to to deal with `PutPartialData`. Another possibility would be to alter the Ibex top-level interface to make it simple to choose between `PutFullData` and `PutPartialData` (see https://github.com/lowRISC/ibex/issues/757).

In conclusion I think we need to decide

1. Do we want the Ibex TL-UL adapater to emit `PutFullData` when it's a full data write or are we happy with `PutPartialData` always?

2. Can devices indicate an error response on sizes/masks they don't like? Must they have to handle `PutPartialData` or could they always indicate error for `PutPartialData` (this is effectively decision 1 in reverse).

We should add something to the Comportability guidelines at the conclusion of this discussions.