Show overloaded Postgres functions as distinct signatures in Studio API docs

[haiderimran019]

Problem

Studio API docs currently identify RPCs by function name and read one parameter schema from PostgREST's Swagger 2 document. When Postgres functions are overloaded, PostgREST exposes only one overload in that document (PostgREST #1154), so Studio cannot display or generate accurate snippets for the other signatures. RpcContent.tsx already carries a TODO for this limitation.

For example, search(term text) and search(term text, limit_count integer) share /rpc/search, but the docs may show only one argument set. A user can copy a snippet for the wrong overload or never discover the other callable signature.

Proposed Studio approach

1. Read exposed database functions from Studio's existing pg-meta/database metadata path, which returns every function OID, schema, argument mode, name, type, and default status.
2. Keep the PostgREST schema as the source for endpoint-level summary/description, but use database metadata as the source for overload signatures.
3. Give each overload a stable UI identity based on function OID while keeping the request endpoint /rpc/{name} unchanged.
4. Display overloads as distinct signatures, such as search(term text) and search(term text, limit_count integer).
5. Generate JavaScript and cURL examples from the selected signature, marking defaulted inputs optional and excluding output-only arguments.
6. Filter through the existing Data API exposure/grant checks so revoked functions are not added to generated docs.

Scope and non-goals

• This would improve Studio-generated API docs only; it would not change PostgREST's Swagger 2 output.
• Existing non-overloaded functions and routes should remain unchanged.
• The first implementation would cover input, input/output, and variadic parameters using existing pg-meta metadata, with focused parser/navigation tests.

Design question

Would maintainers prefer overload selection in the function navigation list (name(type, type)) or a signature selector within a single function page? I lean toward distinct navigation entries because each entry has a stable OID and its generated snippet is immediately unambiguous.