feat(trino): parse WITH FUNCTION ... RETURNS ... RETURN inline UDFs [CLAUDE]

[rusackas]

This re-splits #7926 (closed as too large to review in one pass) into small, incremental PRs per @geooo109's request. This is PR 1 of ~7. I know it's just as many files touched, but it's +154 -15 rather than +493 -16 at least ;)

Trino supports declaring SQL UDFs inline in a WITH clause preceding the query (https://trino.io/docs/current/udf/sql.html):

WITH FUNCTION meaning_of_life()
  RETURNS tinyint
  RETURN 42
SELECT meaning_of_life()

These currently fail to parse (Expecting (). Happens to resolve #5178 (closed), it seems.

This PR is the minimal slice: TrinoParser._parse_cte recognizes a FUNCTION <name>(...) entry in a WITH clause (as opposed to a CTE literally named function, e.g. WITH function AS (SELECT 1)) and parses it into a new exp.FunctionSpecification node, with a mandatory RETURNS clause and a RETURN <expr> body — enough to round-trip the literal example from #5178. Inline functions live in their own WITH clause before the query's own WITH clause per the grammar, so TrinoGenerator.with_sql emits WITH <functions> WITH <ctes> when both are present. walk_in_scope treats FunctionSpecification as opaque so qualify doesn't try to resolve UDF parameters as outer-scope columns.

Next steps (planned follow-up PRs, each gated on the previous)

1. This PR — core WITH FUNCTION ... RETURNS ... RETURN ...
2. Routine characteristics (LANGUAGE, DETERMINISTIC/NOT DETERMINISTIC, CALLED/RETURNS NULL ON NULL INPUT, SECURITY, COMMENT)
3. BEGIN...END block bodies + DECLARE/SET, including the semicolon/chunk-continuation handling so routine bodies don't get split as separate statements
4. IF/ELSEIF/ELSE — reusing/extending exp.IfBlock per review feedback on feat(trino): support inline SQL UDFs (WITH FUNCTION ... SELECT) [CLAUDE] #7926, instead of a new expression type
5. CASE...WHEN...END CASE
6. WHILE...DO...END WHILE — reusing/extending exp.WhileBlock with a label arg, per review feedback
7. LOOP/REPEAT/ITERATE/LEAVE

PRs 4-7 depend on #3 (they all wrap bodies in BEGIN...END); PR 2 and PR 3 are independent of each other, both depending only on this one. Let me know if this subdivision works better. I can "stack" the PRs here if that helps lay out the roadmap, I'll just have to deal with reabases. 😅

Disclosure: implemented with Claude Code, reviewed, tested (make unit, make style) and understood by me (again, I really do look at this stuff. See, it's me, a huuuuuuumannnnn!).

[rusackas]

As mentioned in the PR description, I'm happy to see if we can get through this first, then tackle next steps, or "stack" some PRs (in draft) to show how this will all come together.

[geooo109]

Nice work, thanks for taking into account my comments and breaking the first PR into smaller ones.

[geooo109]

One last comment, we also need to cover this:

  WITH FUNCTION f(x INTEGER) RETURNS INTEGER RETURN x
  WITH RECURSIVE t AS (SELECT 1 AS n)
  SELECT F(n) FROM t

[rusackas]

Thanks for the feedback... digging in!

[rusackas]

Indeed, found and fixed a gap while poking at WITH FUNCTION f(...) ... WITH RECURSIVE t AS (...) SELECT ... failed to parse, since RECURSIVE was only ever checked right after the first WITH token. Fixed in the latest commit, with a test.

[rusackas]

I think/hope we're cleaned up now, but you're a fantastic reviewer, so I'll just cross my fingers for now.