Query txn delta-table ignores staged mutations when compounding operations

This issue is to cover two specific cases that have been discovered as part of the transactions testing work:

• ctx.insert(k01)
• ctx.query('SELECT ...')
• $x = ctx.queryGet(k01)
• ctx.queryReplace($x, ...)

and:

• ctx.insert(k01)
• ctx.query('SELECT ...')
• $x = ctx.queryGet(k01)
• ctx.queryRemove($x)

In both of these cases, it seems like the delta-table correctly reads in all the staged mutations, but when the next operation occurs on the same key, query consolidates them into a singular (but incorrect) operation and doesn't consider the original state of the transaction where documents were already staged.

As an example:

• KV stages an insert k01
• Query picks this up and loads its delta-table with INSERT k01
• Query receives a DELETE k01, it knows that INSERT+DELETE==No-Op and removes it from the delta-table entirely.
• Query commits, delta-table is empty, but an already-staged INSERT has already been performed, query still needs to ensure that this is reflected in the final transaction state by doing the remove operation.

Note that this can also happen in a different scenario with DELETE and then INSERT. These ops can be 'compounded' together into a REPLACE in the delta-table, however the already staged DELETE already exists. This means if the delta-table operation is a replace, the operation list after the delta-table compounding would be a DELETE then a REPLACE, which is not a legal operation.