PostgreSQL CREATE TRIGGER parses execution arguments as data types

## Problem

PostgreSQL trigger execution arguments are literal string constants passed to the trigger function through `TG_ARGV`. The PostgreSQL parser currently routes the `EXECUTE FUNCTION` / `EXECUTE PROCEDURE` tail through `FunctionDesc` / `OperateFunctionArg`, whose arguments represent function declaration data types. As a result, a valid trigger argument is parsed as though it were a data-type declaration and fails at the first literal.

Observed with `sqlparser = 0.62` and `PostgreSqlDialect`.

## Minimal reproductions

```sql
CREATE TRIGGER t_audit
AFTER INSERT ON t
FOR EACH ROW
EXECUTE FUNCTION audit_row('api_key');
```

The legacy PostgreSQL spelling fails the same way:

```sql
CREATE TRIGGER t_audit
AFTER INSERT ON t
FOR EACH ROW
EXECUTE PROCEDURE audit_row('api_key');
```

Both report:

```text
Expected: a data type name, found: 'api_key'
```

The corresponding zero-argument forms parse successfully:

```sql
EXECUTE FUNCTION audit_row();
EXECUTE PROCEDURE audit_row();
```

PostgreSQL accepts both complete trigger statements with the string argument.

## Expected behavior

- Both trigger statements parse successfully under `PostgreSqlDialect`.
- The AST retains `'api_key'` as an execution-time literal/expression (or a trigger-specific argument representation), not as an `OperateFunctionArg` data-type declaration.
- Multiple trigger arguments remain ordered and round-trip through `Display`.
- Function/procedure declaration arguments continue to use the existing data-type-oriented representation.

PostgreSQL's grammar requires trigger arguments here to be string constants. A trigger-specific argument field would therefore also be reasonable if using the general expression AST would accept syntax PostgreSQL itself rejects.

## Downstream context

This was found in Goldziher/scythe#238. Scythe statically parses schema DDL to build a catalog. Triggers do not add catalog state, so scythe skips them after parsing; it still needs sqlparser to accept the valid statement so one trigger does not abort parsing of the entire schema.

I can prepare a focused parser/AST test or implementation once the preferred AST representation is confirmed.

PostgreSqlDialect のトリガー解析から始め、FunctionDesc と OperateFunctionArg を通る EXECUTE FUNCTION および EXECUTE PROCEDURE のパスを追跡します。1 つおよび複数の順序付き文字列引数を対象とする parser と Display の集中的なテストを追加し、宣言引数をデータ型として保持します。両方の形式を正常に解析してラウンドトリップできれば完了です。

索引モデルが issue の本文から書いたものです。