Fix dependency handling: FK ordering, schema normalization, and function replacements

[p-c-h-b]

This patch fixes several bugs in pgschema's dependency handling:

Issues Fixed

1. FK-heavy tables could be reordered alphabetically during cycles: When Kahn's algorithm encountered a cycle, it would fall back to alphabetical ordering, causing child tables to be created before parent tables. The fix breaks cycles deterministically based on source order and defers FK constraints until their referenced tables exist.

2. Schema-qualified identifiers in strings weren't normalized: When the desired schema was applied to a temporary schema, any schema-qualified identifiers inside strings (defaults, policy expressions, trigger bodies, etc.) were left untouched. The diff then emitted SQL that referenced the temp schema name instead of the real schema. The fix normalizes every textual field in the IR so the target schema name is restored everywhere.

3. Function replacements always emitted DROP followed by CREATE: If other objects referenced the function, the drop would fail before the replacement could run. The fix treats replacements as CREATE OR REPLACE operations only, and normalizes argument identities by stripping schema prefixes so public.member_status and member_status aren't treated as different signatures.

4. Updated diff fixtures/tests: Added coverage for deferred FK constraints, policy ordering, and normalized functions.

Patch

I've attached a patch file with the complete fix. The patch is also available in this branch: main...p-c-h-b:pgschema:fix/function-drops

Would you like me to open a PR, or would you prefer to review the patch first?

[p-c-h-b]

Attaching the patch file for review.

[tianzhou]

@p-c-h-b happy to review the patches! 2 requests:

1. Please create separate PRs for each of the issue.
2. Since this is the 1st PR you contribute, please start with a single PR (you can pick any of the 3 to start with). A typical PR contains the implementation as well as the test case e.g. fix: drop trigger/function order #154. Depending on the change, we may add new test case or enhance the existing test case. We can figure out the best way during the PR