Revert optimization breaking deletes

[rkistner]

If a client syncs the following two batches:

1. [PUT row1] (insert row)
2. [PUT row1, REMOVE row1] (update row, then delete row, synced in one batch).

The REMOVE could be an actual delete, or the row just being removed from the bucket.

Then the row was correctly removed from the local ps_oplog table, but not from the data tables. The missing part was in adding the row to ps_updated_rows.

This broken optimization was introduced in b8103bf / #19 / v0.2.0. The remainder of the optimizations in #19 are still valid, but this specific generalization is not. The idea for this optimization was that if a row was both created and removed in the same batch of data, we could ignore those operations completely. However, it did not account for rows that already existed before the sync batch, in which case we can't ignore the remove.

See test case: powersync-ja/powersync.dart#211

To recover from the issue, a client has to re-sync from scratch. Updating to the fixed version will only prevent new cases of the issue from happening, and won't fix existing cases.

Confirmed the fix here with both a unit test (powersync-ja/powersync.dart#211) and manual testing.