Rethinking parallel-scan relation identity checks

In [1] I whined about how the parallel heap scan machinery should have
noticed that the same ParallelTableScanDesc was being used to give out
block numbers for two different relations. Looking closer, there
are Asserts that mean to catch this type of error --- but they are
comparing relation OIDs, whereas what would have been needed to detect
the problem was to compare RelFileLocators.

It seems to me that a scan is fundamentally operating at the physical
relation level, and therefore these tests should check RelFileLocators
not OIDs. Hence I propose the attached. (For master only, of course;
this would be an ABI break in the back branches.) This passes
check-world and is able to catch the problem exposed in the other
thread.

Another possible view is that we should check both physical and
logical relation IDs, but that seems like overkill to me.

Thoughts?

regards, tom lane

[1] https://www.postgresql.org/message-id/2042942.1726781733%40sss.pgh.pa.us