feat(oracle): parse WITH FUNCTION PL/SQL declarations [CLAUDE]

[ebarkhordar]

Fixes #7663

Oracle allows PL/SQL function declarations at the start of a query's WITH clause. Each one ends with its own END;, and any CTEs follow without a comma. The Oracle parser had no path for this, so the issue's query failed with Expecting (.

This is Oracle-only, as suggested in the issue: OracleParser._parse_with picks up FUNCTION <name> entries before handing the rest to the base parser, so Trino's WITH FUNCTION path is untouched. The signature (parameters, RETURN type) is parsed into a FunctionSpecification, the same node Trino produces. The body after IS/AS is kept verbatim as a Var, since there is no PL/SQL statement grammar to parse it with.

The body's own semicolons split it across statement chunks, so the parser steps through the chunks to find the END that closes the function. BEGIN and CASE open a level, and END IF/END LOOP are skipped. A nested function in the declaration section has its own body and is handled recursively. The existing block parser used by CREATE PROCEDURE doesn't fit here, because it consumes every remaining statement and wouldn't stop before the SELECT.

The generator writes the declarations back in Oracle form, and a body that is not PL/SQL (e.g. one parsed from Trino) is still reported as unsupported when generating Oracle. Function headings with options such as DETERMINISTIC or PIPELINED, and WITH PROCEDURE, are not handled yet and still fail to parse.

Tests in test_oracle.py cover the issue's query, several functions plus a CTE, AS, nested blocks and loops, a nested subprogram, a following statement, and the error cases. The unit suite passes on 3.9, 3.12 and 3.14, as do the mypyc build on 3.14, ruff and mypy. I used Claude to help write this, and I have not run these queries against a real Oracle instance.

[georgesittas]

I don't think this is the right approach. We already parse Trino inline UDFs, including their actual definition; we shouldn't store the function logic as plain-text.

Also, this PR is doing a lot. We should split it into minimal PRs adding incremental support for this Oracle syntax.