Use relative field numbers in UPDATE request, not absolute

Right now, when an UPDATE statement carries a number of commands, each command argument (field number) is identified by field offset (number) in the original tuple.

For example, if we have a tuple with 3 fields, and would like to insert a field between fields 1 and 2 (indexing starts at 0), and append a field a the end, we write:
update (insert <1, value>, set <3, value>)

When the same command is run in two statements, the same semantics has to be achieved using different field indexes:
update (insert <1, value>)
update (set<4, value>) -- sic, here we have a new field number, since this command operates oon a tuple of a bigger length.

This is considered by some counter-intuitive.
Indeed, it's easy to view an UPDATE which consists of multiple command as a multi-update, packed into a single one for efficiency.
From semantics point of view, however, it should not be a different set of commands: whether or not these commands go in the same UPDATE, or in two separate ones.

Therefore, we should implement a new indexing scheme of fields in UPDATE commands, when each field index is relative to the state of the tuple at the moment when this command is applied.

When these changes are implemented, a multi-field UPDATE code would look the same
as a multi-update code, for example:

update (insert<1, value>, set<4, value>) -- inserts a field between field 1 and 2, and appends
a new field at the end.