foreign_key test is sensitive to the OID counter

While running installcheck against a long-lived cluster, I got a diff
in the foreign_key test:

@@ -2045,11 +2045,11 @@
ORDER BY oid::regclass::text;
conname | conenforced | convalidated
------------+-------------+--------------
+ selffk_3 | t | f
+ selffk_3_1 | t | f
selffk | t | f
selffk_1 | t | f
selffk_2 | t | f
- selffk_3 | t | f
- selffk_3_1 | t | f
(5 rows)

At first I thought the planner patch I was working on had caused an
unexpected plan diff, and wasted some time chasing that. But it
turned out to be the "ORDER BY oid::regclass::text" in these queries.

These OIDs are constraint OIDs, not relation OIDs, so the regclass
cast just renders them as numeric strings, and comparing those as text
depends on the number of digits. Once the OID counter crosses a power
of ten while the test runs, '1000006' sorts before '999987' and the
output order flips.

I plan to push the attached patch to fix it. Any thoughts?

- Richard