Fix dependency ordering

[da77a]

Fix dependency ordering for functions, views

Functions and views can depend on each other in ways that pg_depend does
not fully track.

This commit fixes four classes of missing dependencies:

1. Function → table/view (composite type returns)
   Functions using tables/views as composite return types (RETURNS view_name)
   have pg_depend entries that were not being queried. Add a table_dependencies
   subquery to GetProcs that finds these via pg_depend.

2. Function → table/view (body references)
   plpgsql functions using %ROWTYPE, type[], or FROM/JOIN in their bodies
   have no pg_depend entries (they are resolved at runtime).
   So added simple parsing of pg_get_functiondef() output to find these.

3. View → view (dependency query bug)
   The GetViews table_dependencies subquery had existing issues:

   • Only included tables (relkind r,p) — views were excluded
   • No self-reference exclusion (views appeared to depend on themselves)
   • Missing r.ev_class = c.oid constraint caused false positives from
     other views' rewrite rules, creating spurious cycles

4. View → function
   Views calling functions in their definition (SELECT * FROM some_function()).
   Add function_dependencies to GetViews via pg_depend and ordering in the view vertex generator.

Closes #248
Related: PR #268 (partial fix for case 1, abandoned due to cycles caused by case 3)

---

Testing

Validated against a substantial (~ 1000 object) schema containing views, functions, tables, triggers that exercises all four cases.

The reproducer from #248 (function with RETURNS view_type ordered before the view) is resolved.

Notes

• Case 1 is based on the approach from PR Account relation dependencies used by routines as composite types #268 by @jesse-sivonen. The circular dependency issue that caused that PR to be abandoned looks to have been case 3 (the view query bug), nothing specific to the function dependency patch itself.
• Case 2 uses regex-based text parsing which may produce false-positive dependencies (e.g. matching table names in string literals). False positives only add unnecessary ordering constraints (tempting to exploit this for remaining blind spots like types)
• The HAS_UNTRACKABLE_DEPENDENCIES hazard is still emitted for plpgsql functions since text-based detection is best-effort.

[cla-assistant]

All committers have signed the CLA.

[da77a]

Fixes #282, fixes #283, fixes #284