Extend LF line-ending normalization to remaining runtime generators #1345

Context

#1331 added LfNormalizingFileSystemAccess and wired it into CheckGenerator and CheckCfgGenerator so generated output is LF regardless of host OS. The same risk pattern exists in three other runtime IGenerator/IGenerator2 classes that emit Java sources to committed src-gen/ directories — they were not addressed in #1331.

Generators with the same risk

Plus an FSA-bypass writer that needs separate handling:

• KeywordAnalysisHelper uses raw PrintWriter (.println() → platform line separator) at lines 183, 444, 448 — writes report and documentation files to srcGenPath. The decorator-wrapper approach doesn't apply here; fix is either explicit \n or a BufferedWriter with explicit LF.

Why this matters

.gitattributes (* text=auto eol=lf) normalizes on commit, so the committed state and the line-endings CI check stay green. The value is preventing working-tree noise for Windows developers: after regeneration, every file shows as modified in git status/git diff due to EOL drift relative to the index.

Suggested approach

1. Hoist LfNormalizingFileSystemAccess from com.avaloq.tools.ddk.check.core to a shared bundle (e.g. com.avaloq.tools.ddk.xtext) so the three generators above can depend on it without pulling in check.core.
2. Wrap the FSA at the entry of each doGenerate(...) in the same pattern as fix: normalize line endings in check generators #1331.
3. Decide whether KeywordAnalysisHelper is in scope — if yes, fix via explicit \n rather than the wrapper.

Out of scope

• MWE2 *Fragment2 classes (build-time workflow only, route through Xtext's IXtextGeneratorFileSystemAccess — separate path).
• Per-test generators (TestLanguageGenerator) — their output isn't committed.

Left by Claude at João's request.