Halloween queries get explicit buffering

This makes our handling of a query like `UPDATE t SET id=id+1` compliant with the SQL standard (i.e. select appears to happen before any update). As such, we are now consistent with Oracle/SQLServer instead of Postgres/SQLite/MySQL.

Instead of relying on the StoreAdapter step interface methods, adjust the actual plan to use Buffer and, if required, a Delete + Insert pair.

Buffer_Default is fairly straight forward and uses the sorter from the adapter for spilling large input sets. The ordering is determined from an artificial counter that is packed into a CompoundRow along with the real one. An option I toyed with was using MergeJoinSorter directly and skipping the sort phase altogether, but that is somewhat of a refactor. Minor tweaks to ValuesHolderRow to facilitate the new usage.

The actual transformation takes place in HalloweenRecognizer. An attempt is made to continue to use the Update operator where possible (INSERT, DELETE and non-unique index UPDATEs). Otherwise, the plan's Update is removed and replaced with Delete/Buffer/Project/Insert. There is a TODO about pushing the Buffer farther down the tree when possible (e.g. under Flatten and BaseLookup), which would buffer index rows instead of table rows, but the rest of the stack doesn't currently like that much.

Removed now unused references to step/isolate variables and methods.

Note that the test change in `execute-free-form.expected` isn't due to a new plan, but rather the previous was incorrect (i.e. step wasn't promoted between statements).