pgsql: Fix EvalPlanQual bug when query contains both locked and not-loc

Fix EvalPlanQual bug when query contains both locked and not-locked rels.

In commit afb9249d06f47d7a, we (probably I) made ExecLockRows assign
null test tuples to all relations of the query while setting up to do an
EvalPlanQual recheck for a newly-updated locked row. This was sheerest
brain fade: we should only set test tuples for relations that are lockable
by the LockRows node, and in particular empty test tuples are only sensible
for inheritance child relations that weren't the source of the current
tuple from their inheritance tree. Setting a null test tuple for an
unrelated table causes it to return NULLs when it should not, as exhibited
in bug #14034 from Bronislav Houdek. To add insult to injury, doing it the
wrong way required two loops where one would suffice; so the corrected code
is even a bit shorter and faster.

Add a regression test case based on his example, and back-patch to 9.5
where the bug was introduced.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/71404af2a29ce4a3a5907cdc8b893ec2bc0285b4

Modified Files
--------------
src/backend/executor/nodeLockRows.c | 40 ++++++++++++--------------
src/test/isolation/expected/eval-plan-qual.out | 19 ++++++++++++
src/test/isolation/specs/eval-plan-qual.spec | 23 +++++++++++++++
3 files changed, 60 insertions(+), 22 deletions(-)