Add support for PostgreSQL procedures (CALL-based mutations)

[dargmuesli]

Summary

Adds support for PostgreSQL PROCEDUREs (introduced in PG11), resolving graphile#1309. Previously a procedure either didn't appear in the schema or got built into a GraphQL field that crashed at query time, since Postgres procedures can only be invoked with call proc(...), never embedded in a select like a function.

• @dataplan/pg: new PgCallStep/pgCall() step that builds and executes a call statement directly, including the positional-argument handling procedures require (every parameter, including OUT-only ones, needs a value) and raw-text decoding for the output columns (which can't be wrapped in ::text casts the way a select list can).
• graphile-build-pg: PgProceduresPlugin detects prokind = 'p' and builds a CALL-backed resource; procedures are always mutation fields, since they can never appear in a query, computed column, or connection. PgCustomTypeFieldPlugin's clientMutationId wiring is extended to recognize PgCallStep results alongside PgSelectStep ones.
• Test coverage: a new procedures schema (PG11+) covering no-output, single-output, multiple-output, and INOUT procedures, plus a mutation test exercising each including clientMutationId.
• Docs: procedures.md now documents the feature and its limitations instead of saying it's unsupported.

Known limitation: a single-output procedure's result is a nested object ({ result { doubled } }) rather than flattened to a bare scalar the way single-output functions are, since Postgres reports record as a procedure's return type even with just one OUT parameter.

[dargmuesli]

Superseded by graphile#3124, opened against upstream instead.