Fix string-bodied CREATE FUNCTION swallowing the next statement

[murrayju]

Problem

The library fails to split the following into two statements:

create function foo() returns void as 'select 1' language sql;
SELECT 1;

It is parsed as a single CREATE_FUNCTION that greedily consumes the trailing SELECT 1;.

The bug is broader than the single reported case — it affects any CREATE FUNCTION/PROCEDURE whose body is a quoted or dollar-quoted string (PostgreSQL/Snowflake/standard SQL), and PostgreSQL CREATE TRIGGER (which only references a function). These only worked before when they happened to be the last statement, since end-of-input terminated them.

Root cause

CREATE_FUNCTION/CREATE_PROCEDURE/CREATE_TRIGGER are in statementsWithEnds, so a semicolon only terminates them once statement.canEnd is set — and canEnd is only set when a BEGIN...END block closes. When the body is a single string/dollar-quoted token (no block) or the trigger has no body, canEnd was never set, so the statement swallowed everything after it.

Fix

• Set canEnd once a string/dollar-quoted body has been consumed at the top level following the AS keyword (CREATE FUNCTION/PROCEDURE).
• Make statementsWithEnds dialect-aware: exclude CREATE_TRIGGER for PostgreSQL/Snowflake, where triggers have no inline body.

The block-based canEnd logic is left intact, so T-SQL bodies (e.g. mssql triggers with IF ... RETURN; before a BEGIN...END) still protect their token-level semicolons.

Tests

Added a multiple-statement describe block covering:

• the reported string-literal body case
• dollar-quoted bodies (incl. dollar-quoted plpgsql with internal BEGIN...END)
• PostgreSQL bodyless triggers
• a regression guard for mssql BEGIN...END function bodies

All existing tests continue to pass.