sql: create named composite type per table

[nvanbenschoten]

Needed for #69010.

In Postgres, whenever you create a table, a composite type is also automatically created, with the same name as the table, to represent the table's row type.

See https://www.postgresql.org/docs/current/rowtypes.html#ROWTYPES-DECLARING.

Epic CRDB-10485

[ajwerner]

This tiny issue encapsulates a bigger project. We need to think about how to fit composite and record types into our type system. We could support these record types and not user-defined other record types as a stepping stone.

Things to note:

• We need to allocate a distinct regtype oid for both the record type and its corresponding array type.
• We'll want to decide how we could look those up efficiently.
• We need to decide whether we want a new type descriptor or to synthesize the type descriptor from the table descriptor (probably?).
• We'll need to think about type hydration so that we properly invalidate the usages of the record types in the face of changing table versions

In the first pass we probably won't want to allow these record types to be used in columns, that will lead to an interesting limitation on views.

[jordanlewis]

We could conceivably get away with doing less than all of this if we just wanted to support these types in the context of the JSON recordset functions, which could be a win on its own.

[rafiss]

Additional context: We added a virtual representation of these composite types to pg_type in #66815. We skipped over the problem of how to represent the composite array type. If we fully implement these composite types, some of this pg_catalog logic might have to change. (Potentially in a way that's not great for mixed-version clusters, but if we really need to we can version-gate it; and also in a way that's no worse than other pg_catalog changes we've unintentionally made in the past.)

For some more background, see the discussion on #66576