Optimizing RelationFindReplTupleSeq() for CLOBBER_CACHE_ALWAYS

When testing commit c6b9204 with CLOBBER_CACHE_ALWAYS, of the 20 hours for
check-world, 001_rep_changes.pl took 1.8 hours.  At commit 5406513, the test
failed at a poll_query_until() timeout[1].  The slow part is the logical
replication of "DELETE FROM tab_ins WHERE a > 0", which deletes 100 records
from a table of ~1100 records, using RelationFindReplTupleSeq().
tuples_equal() called lookup_type_cache() for every comparison.  Performing
those lookups once per RelationFindReplTupleSeq(), as attached, cut the test's
runtime by an order of magnitude.  While performance for CLOBBER_CACHE_ALWAYS
is not important, this is consistent with record_eq() and is easy.  I'm
slightly inclined not to back-patch it, though.

[1] This seemed to result from the poll query being 2-3x faster at commit
5406513, not from logical replication being slower.  (poll_query_until() times
out after 1800 polls separated by 0.1s sleeps, however long that takes.)  I
had guessed that commit 1c7a0b3 greatly accelerated this test case, but it
gave about a 4% improvement under CLOBBER_CACHE_ALWAYS.