Normalize whitespace in rendered template output

[kojiromike]

What

Generated code currently carries per-line trailing whitespace, and rendered files don't consistently end in a newline. This normalizes both at the single render chokepoint in Templates, so every generated file (core, version core, type classes, and tests) comes out free of trailing whitespace and ending in exactly one newline.

Why

Templates are PHP files rendered via output buffering. Indented inline control structures — e.g. <?php endif; ?> — emit their leading indentation as whitespace-only or trailing-whitespace lines in the output. Because every template returns through Templates::render*, a single normalize() step there cleans every generated file at once, with no need to touch the individual templates.

How it was verified

• phpunit -c phpunit/Builder.xml — all 70 tests pass.
• Generated DSTU1 before vs. after: 6,639 trailing-whitespace lines across all 446 files → 0, and 0 files not ending in exactly one newline. Diffing the two trees (after stripping trailing whitespace and ignoring embedded generation timestamps) shows the change is whitespace-only — no functional difference in the generated code.

Is there appetite for more of this?

This is deliberately a small, self-contained first step. While digging in, I noticed a few other places where the generator could emit higher-quality code straight out of the box, and I'd be happy to send follow-up PRs if you're open to it:

• Unused use imports — some imports (Constants, FHIRVersion, container interfaces) are added speculatively per type-category even when a given type's body never references them, so they show up as unused.
• Modern PHP idioms — __CLASS__ and get_class($x) in the templates could become self::class / $x::class.
• A CI quality gate — optionally, a phpcs (and/or rector) check that runs against generated output in the existing version matrix, so output quality is enforced rather than something each downstream consumer re-cleans on their own.

Totally understand if some or all of that is out of scope or not the direction you want — happy to take your lead. Mainly wanted to ask before investing further. Thanks for maintaining php-fhir!

[dcarbone]

This looks good to me! I am all for sensible code quality improvements!