Keep generated renderers JIT-compilable

[gregjotau]

Why

Large fully expanded templates were producing render methods above HotSpot’s default 8,000-byte huge-method threshold. HotSpot then kept those hot page renderers interpreted; the diagnostic Utiin page was 2.8x faster when huge-method compilation was forced.

What changed

• Partition generated renderers at safe template boundaries, carrying loop/form bindings as typed captures.
• Cache th:object and select values once per render scope.
• Replace Spring stream lookups with allocation-free loops and fast-path a single TemplateSet.
• Avoid SpringRequestDataValues when no processor exists.
• Reduce the Spring-side scratch buffer from 16 KiB to 1 KiB.
• Add an oversized generated-page regression test that inspects classfile code lengths.
• Release as 0.6.0.

Verification

• ./gradlew clean build
• Compiled Vymo, ecomtools, Utiin, and Eteo against this checkout.
• Inspected 136 generated renderers: maximum method sizes are 4,050 B (Vymo), 3,811 B (ecomtools), 4,263 B (Utiin), and 3,311 B (Eteo); none are at or above 8,000 B.

[gregjotau]

@lehoanggiap I’m tagging you because this changes the generated-code shape and cuts a release. The key justification is HotSpot’s default DontCompileHugeMethods behavior: real Eteo/Utiin pages had 8–11 KB render methods and stayed interpreted. Safe boundary partitioning keeps every measured renderer under 4.3 KB without introducing a runtime template tree or changing Thim’s compact static-byte layout. The Spring changes are deliberately small allocation reductions, and the new classfile regression test makes the JIT constraint enforceable going forward.