OID ordering dependency in pg_dump

While starting to poke at the hashed-enum-partition-key problem
recently discussed [1], I realized that pg_dump's flagInhAttrs()
function has a logic issue: its loop changes state that will be
inspected in other iterations of the loop, and there's no guarantee
about the order in which related tables will be visited. Typically
we'll see parent tables before children because parents tend to have
smaller OIDs, but there are plenty of ways in which that might not
be true.

As far as I can tell, the implications of this are just cosmetic:
we might dump DEFAULT or GENERATED expressions that we don't really
need to because they match properties of the parent. Still, it's
buggy, and somebody might carelessly extend the logic in a way that
introduces more-serious bugs. PFA a proposed patch.

regards, tom lane

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