Report the real syntax error for invalid script definitions

[bentsherman]

Close #7009
Close #7050

When a process, workflow, agent, or output definition fails to parse, the parser falls back to parsing it as a statement: process foo { ... } is a command expression and workflow { ... } is a method call with a closure-with-labels. So any syntax error inside a definition ended in the same generic error, highlighted over the whole definition:

Invalid process definition -- check for missing or out-of-order section labels

This PR re-parses such statements as a script declaration. The re-parse can't fall back to a statement, so the parser reports the actual syntax error at the offending token. No grammar changes, and valid scripts are only parsed once.

Case	Before	After
process 'MY-MODULE' { (#7009)	1:1 Invalid process definition ...	1:9 Unexpected input: ''MY-MODULE''
sample1: Sample = ... in a workflow (#7050)	whole workflow highlighted	Unexpected input: ':' on that line
output: before input:	whole process highlighted	error at the misplaced input:
take: after main:	whole workflow highlighted	Unexpected input: ':' on take:
emmit: typo	whole workflow highlighted	Unexpected input: ':' on emmit:

The messages are still the terse Unexpected input: ..., but now they point at the right place. One case is arguably worse: a definition missing a required section (e.g. an agent without prompt:) now reports Unexpected input: '}' at the closing brace instead of hinting at section labels. Better wording belongs in DescriptiveErrorStrategy, as a follow-up.

I also tried a semantic predicate on the top-level statement alternative to block the fallback in the grammar. It doesn't work because ANTLR evaluates the predicate after rewinding the input, so the error is reported at the process keyword again.

[netlify]

✅ Deploy Preview for nextflow-docs canceled.

Name	Link
🔨 Latest commit	61b790b
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs/deploys/6abc06d6d05c390008664e99

[jorgee]

The PR fixes most of the cases by providing a better error message; however, when there is a definition without body (process foo with no { ... }), it reports its error in the wrong place. The definition is parsed as a call, process(foo). The re-parse then fails on the first token after the statement, so the error lands outside the definition. For instance:

Input	Before	After
process foo, a comment, then workflow { at line 7	error on the process foo line	7:1 Unexpected input: 'workflow'
process foo on the last line (line 6)	error on the process foo line	7:1 Unexpected input: ''

I have created #7712 with a suggestion for fixing this case.

The rest sounds good to me.

[bentsherman]

Thanks for the review. I closed your stacked PR because I'm wary of going too far down this rabbit trail. There will always be edge cases to improve but I don't want to bloat the parser too much. Let's revisit if we get user feedback about it