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.

Beginne bei der Trigger-Analyse von PostgreSqlDialect und verfolge die Pfade EXECUTE FUNCTION und EXECUTE PROCEDURE durch FunctionDesc und OperateFunctionArg. Füge fokussierte Parser- und Display-Tests für ein sowie mehrere geordnete String-Argumente hinzu und bewahre die Deklarationsargumente als Datentypen. Als abgeschlossen gilt die Aufgabe, wenn beide Formen erfolgreich geparst und wieder in ihre ursprüngliche Darstellung umgewandelt werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.