pgsql: Use "concurrent delete" in serialization error for TM_Deleted ca

Use "concurrent delete" in serialization error for TM_Deleted cases

In ExecLockRows() and ri_LockPKTuple(), the TM_Deleted code path was
using the same "could not serialize access due to concurrent update"
message as the TM_Updated path. Use "concurrent delete" instead, since
the tuple was deleted, not updated. The ExecLockRows() instance was
likely a copy-paste error per Andres; the ri_LockPKTuple() instance
was carried over from the same pattern in commit 2da86c1ef9.

Update affected isolation test expected files accordingly and add
a new test to fk-concurrent-pk-upd.spec with concurrent delete of the
PK row.

The ExecLockRows() change is master-only for lack of user complaints
and to avoid breaking anything that might match on the error text.

Reported-by: Jian He <jian.universality@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>
Discussion: /messages/by-id/CACJufxEG1JTCq4A1gnNAu-bGAq9Xn=Xkf7kC3TRWFz6iuUOuRA@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/410013d2a5917ee8978c944e582e323acc9ebdcf

Modified Files
--------------
src/backend/executor/nodeLockRows.c | 2 +-
src/backend/utils/adt/ri_triggers.c | 2 +-
src/test/isolation/expected/fk-concurrent-pk-upd.out | 20 ++++++++++++++++++++
src/test/isolation/expected/fk-partitioned-2.out | 4 ++--
src/test/isolation/expected/fk-snapshot-2.out | 4 ++--
src/test/isolation/expected/fk-snapshot-3.out | 4 ++--
src/test/isolation/specs/fk-concurrent-pk-upd.spec | 3 +++
7 files changed, 31 insertions(+), 8 deletions(-)