Bandwidth Optimisations

currently the bandwidth is one of the more expensive costs of stdb.
part of that is that deleted rows are send as full row even if the PK alone would be enough for the client.
for high update rate tables, this means it is sending almost double the data than it should be.
for row updates, it wouldn't even need the delete row at all as the client can just check if it has the pk in local cache and generate the update callback with just the new insert row.
so in short:

• deleted rows with PK could just be the PK
• updated rows with PK could just be the new insert row and no deleted row.
• rows without PK would still need to be send in full
  but still this would likely cut down the bandwidth by close to 50% with just that small change.

Requested by @xDovos via the SpacetimeDB site.

Start by tracing how row inserts, updates, and deletes are serialized and delivered to clients, focusing on the handling of primary-key and keyless rows. Verify that keyed deletes send only the primary key, keyed updates send only the new row, and keyless-row behavior remains unchanged while checking the resulting bandwidth and client callbacks.