Handle mixed returnable and non-returnable columns better in IOS.

We can revert the code changes of commit b5febc1d1 now, because
commit 9a3ddeb51 installed a real solution for the difficulty
that b5febc1d1 just dodged, namely that the planner might pick
the wrong one of several index columns nominally containing the
same value.  It only matters which one we pick if we pick one
that's not returnable, and that mistake is now foreclosed.

Although both of the aforementioned commits were back-patched,
I don't feel a need to take any risk by back-patching this one.
The cases that it improves are very corner-ish.

Discussion: https://postgr.es/m/3179992.1641150853@sss.pgh.pa.us

contrib/btree_gist/expected/inet.out

@@ -83,13 +83,13 @@ SELECT count(*) FROM inettmp WHERE a  = '89.225.196.191'::inet;
 
 DROP INDEX inetidx;
 CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
--- likewise here (checks for core planner bug)
+-- this can be an index-only scan, as long as the planner uses the right column
 EXPLAIN (COSTS OFF)
 SELECT count(*) FROM inettmp WHERE a  = '89.225.196.191'::inet;
-                     QUERY PLAN                     
-----------------------------------------------------
+                       QUERY PLAN                        
+---------------------------------------------------------
  Aggregate
-   ->  Index Scan using inettmp_a_a1_idx on inettmp
+   ->  Index Only Scan using inettmp_a_a1_idx on inettmp
          Index Cond: (a = '89.225.196.191'::inet)
 (3 rows)
 

contrib/btree_gist/sql/inet.sql

@@ -42,7 +42,7 @@ DROP INDEX inetidx;
 
 CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
 
--- likewise here (checks for core planner bug)
+-- this can be an index-only scan, as long as the planner uses the right column
 EXPLAIN (COSTS OFF)
 SELECT count(*) FROM inettmp WHERE a  = '89.225.196.191'::inet;