There are two bits of added functionality needed to make this work:
1. We need to abstract the storage type. The patch does this by teaching catalog/index.c to recognize an opckeytype specified as ANYELEMENT with an opcintype of ANYARRAY, and doing the array element type lookup at index creation time.
2. We need to abstract the key comparator. The patch does this by teaching gin/ginutil.c that if the opclass omits a GIN_COMPARE_PROC, it should look up the default btree comparator for the index key type.
Both of these seem to me to be reasonable general-purpose behaviors with potential application to other opclasses.
In the aforementioned message I worried that a core opclass defined this way might conflict with user-built opclasses for specific array types, but it seems to work out fine without any additional tweaks: CREATE INDEX already prefers an exact match if it finds one, and only falls back to matching anyarray when it doesn't. Also, all the replaced opclasses are presently default for their types, which means that pg_dump won't print them explicitly in CREATE INDEX commands, so we don't have a dump/reload or pg_upgrade hazard from them disappearing.
A potential downside is that for an opclass defined this way, we add a lookup_type_cache() call to each initGinState() call. That's basically just a single dynahash lookup once the caches are populated, so it's not much added cost, but conceivably it could be measurable in bulk insert operations. If it does prove objectionable my inclination would be to look into ways to avoid the repetitive function lookups of initGinState, perhaps by letting it cache that stuff in the index's relcache entry.
