fix: run the Spoon pipeline on a thread with a configurable stack size

[monperrus]

Summary

Alternative to #6805 for #6804: give the Spoon pipeline a stack proportional to the problem, instead of rewriting individual visitors iteratively.

Problem

Spoon's visitors are recursive — one JVM frame per AST node on the path from the root to the node being visited. OpenJDK's valid DeepStringConcat.java has ~32,000 binary operators in one expression, which exhausts the default thread stack of a few hundred kilobytes.

AstParentConsistencyChecker and ProcessingVisitor are the two visitors named in the issue, but they are only the first two to be reached. On current master, with the 32k-operator file:

operation	default stack	16 MB thread
buildModel() — parent check	SOE	OK
process() — processors	SOE	OK
prettyprint()	SOE	OK
getElements(filter)	SOE	OK
root.toString()	SOE	OK
root.clone()	SOE	OK
equals	SOE	OK

The recursion lives in CtScanner, EarlyTerminatingScanner, LexicalScopeScanner, CloneVisitor, EqualsVisitor, DefaultJavaPrettyPrinter and every user-written CtScanner subclass. Binary operators are also only the easiest deep chain — nested if/else and long .a().b().c() chains recurse the same way. Making visitors iterative one at a time does not converge.

Change

Launcher runs buildModel(), process(), prettyprint() and run() on a thread whose stack size is Environment#getStackSize().

• Default 64 MB, 4x the measured requirement. The stack is reserved address space, not committed memory: pages are only committed as the stack actually grows, so it costs nothing on ordinary models.
• setStackSize(0) runs the pipeline on the calling thread, restoring today's behaviour for embedders that manage their own threads.
• Nested steps reuse the thread the outermost step created, so run() spawns one thread, not four.
• Exceptions propagate to the caller unchanged: a RuntimeException or Error is rethrown as-is, anything else is wrapped in SpoonException.
• The two new Environment methods are default, so third-party Environment implementations keep compiling.

+140 lines of main code, against 373 in #6805, and it covers seven operations rather than two.

Known limitation

A user calling element.toString() or getElements() on their own thread, outside the launcher, is not covered — they can size their own thread, and Environment#getStackSize()'s Javadoc says so. Nothing short of rewriting every visitor covers that case.

Validation

• DeepExpressionTest#testDeepExpressionPipeline builds, processes and pretty-prints the 32k-operator expression, then asserts that the processor saw all 32,000 operators and that the printed file contains all 32,000 +. It runs in ~6 s.
• Verified non-vacuous: with setStackSize(0) the same test fails with StackOverflowError.
• Three further tests cover setStackSize(0), single-thread reuse across nested steps, and rejection of a negative stack size.
• Full suite and checkstyle left to CI.

[SirYwell]

This has the potential of a significant slowdown when invoking the relevant methods for small elements, right?

On Java 21, we could use virtual threads which would be cheaper in that aspect. Other than that, are there more sophisticated patterns to avoid stack overflows for deep visitor-based interactions?