fill_extraUpdatedCols is done in completely the wrong place

I happened to notice $subject while working on the release notes.
AFAICS, it is 100% inappropriate for the parser to compute the
set of generated columns affected by an UPDATE, because that set
could change before execution. It would be really easy to break
this for an UPDATE in a stored rule, for example.

I think that that processing should be done by the planner, instead.
I don't object too much to keeping the data in RTEs ... but there had
better be a bold annotation that the set is not valid till after
planning.

An alternative solution is to keep the set in some executor data structure
and compute it during executor startup; perhaps near to where the
expressions are prepared for execution, so as to save extra stringToNode
calls.

regards, tom lane