[BUG] function materialization does not handle signature changes (parameter renames, return type changes)

## Feature request

### Problem

PostgreSQL's `CREATE OR REPLACE FUNCTION` cannot rename parameters or change return types in certain ways. Attempting to do so raises:

```
cannot change name of input parameter "old_name"
```

or

```
cannot change return type of existing function
```

Currently, the only workaround is to manually `DROP FUNCTION` before running `dbt build`. This is error-prone and requires either a migration script or direct database access. There is no built-in dbt mechanism to handle this.

### Proposed solution

`dbt build --full-refresh` should be supported for function materializations. When `--full-refresh` is passed (or when `full_refresh=true` is set in the model config), the function materialization should:

1. Execute `DROP FUNCTION IF EXISTS .()` before the `CREATE FUNCTION`.
2. Then proceed with the normal `CREATE FUNCTION` / `CREATE OR REPLACE FUNCTION` flow.

This mirrors how `--full-refresh` works for incremental models (which fall back to a full `CREATE TABLE` after dropping the existing one), and for materialized views.

### Use cases

- **Parameter renames**: e.g. renaming `partner_id` → `input_partner_id` to follow a naming convention.
- **Return type changes**: adding or removing columns from a `RETURNS TABLE(...)` function.
- **Argument type changes**: changing an argument from `text` to `uuid`.

### Current workaround

Manually drop the function via a migration macro before rebuilding:

```bash
dbt run-operation drop_function --args "{name: 'f_example', arg_types: 'int'}"
dbt build --select f_example
```

This requires a custom `drop_function` macro and a migration entry in `pre.json` for each rename — significant overhead for a routine refactoring operation.

### Environment

- dbt-core version: 1.11.4
- Adapter: dbt-postgres 1.10.0
- Database: PostgreSQL