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.

Start at PostgreSqlDialect trigger parsing and trace the EXECUTE FUNCTION and EXECUTE PROCEDURE paths through FunctionDesc and OperateFunctionArg. Add focused parser and Display tests for one and multiple ordered string arguments, preserving declaration arguments as data types; done means both forms parse and round-trip successfully.

Written by the indexing model from the issue text.