Fix issue with indexes not properly updating in SDKs if no primary_key is specified

From @SteveBoytsun:

It took me 2+ hours of torturing stdb, but I finally found a repro. Here are the steps:

1. Define a table with unique column and a non-unique column (NO PK)
2. Insert some values into said table
3. Subscribe to that table
4. Call a reducer that modifies non-unique values
5. !Profit
   The issue happens because

• Client SDK doesn't treat these changes as updates - instead they're delete+insert
• Due to how we calculate diffs on the client, inserts are performed before deletes, which means that indexes are updated and subsequently deleted
  A workaround for that issue is to always have a PK. As for proper fix, I would recommend making sure that we do all deletes BEFORE inserts.

Incidentally, this is part of what I did last week to optimize chunk crossing in BitCraft. I discussed it with @cloutiertyler as purely an optimization, and he suggested sitting on it until after 0.12, but since there's a bug that can be fixed by those changes it may be worth re-evaluating when to do it. Changes are ~2.5/5 on complexity scale (and it's not trivial to separate them from the rest of optimizations), but they are already somewhat-tested in BitCraft.

Note: this may also be an issue in other client SDKs

Start by reproducing the reported case: a table with unique and non-unique columns but no primary key, followed by a subscription and reducer update to non-unique values. Trace the client SDK diff and index-update paths, including the other SDKs noted in the issue; done means indexed values remain correct after the update without requiring a primary key.