Preserve generic type parameters in AutowiredFieldIntoConstructorParameterVisitor

[MBoegers]

• Closes AutowiredFieldIntoConstructorParameterVisitor loses generic type parameters #1005.

• Big thanks to @dim-kod for the upfront investigation and the clear reproduction in AutowiredFieldIntoConstructorParameterVisitor loses generic type parameters #1005 / Fix generic type loss in AutowiredFieldIntoConstructorParameterVisitor (fixes #1005) #1006 — it pinned down the root cause and surfaced all the edge cases (nested generics, wildcards, arrays) that this needed to handle. This is a smaller take on the same fix, leaning on existing utilities.

What's changed?

AutowiredFieldIntoConstructorParameterVisitor rendered the generated constructor parameter type with TypeUtils.asFullyQualified(type).getClassName(), which drops type arguments — so an @Autowired List<String> field became a raw List parameter (and array fields were skipped entirely).

• New-constructor path (AddConstructorVisitor): render the field's TypeTree source text directly in the template. Because the template is contextSensitive() and the field stays in the class, its imports are already present — no import registration needed.
• Existing-constructor path (AddConstructorParameterAndAssignment): the replaceParameters() template is parsed without the file's imports, so the parameter is rendered fully qualified via TypeUtils.toString(..) and then simplified with service(ImportService.class).shortenFullyQualifiedTypeReferencesIn(..) — the same idiom ChangeMethodParameter already uses in this repo. This also fixes array fields into an existing constructor, which previously threw.
• The type guard now skips only null/primitive types instead of everything without a FullyQualified, letting arrays and type variables through.

Why this shape

The fix itself is just rendering the type from the LST instead of getClassName(). No recursive FQN-collection helper is needed: imports are already in scope on the new-constructor path, and ImportService handles them on the existing-constructor path. Net production change is ~23 lines.

Tests

Covers generics into new/existing/parameterized constructors, nested generics (incl. into an existing constructor, under full type validation), bounded wildcards, user-defined generic types across packages, and arrays. Two tests relax TypeValidation to document current JavaTemplate limitations (the template parser can't resolve sibling in-run sources; array assignments are mis-attributed upstream) — each annotated with the precise reason.

[timtebeek]

Nice to see this minimal fix, thanks!

[dim-kod]

Hello @MBoegers, I am satisfied with the result. It is always better to have simpler fixes! Thank you once again, closing the other PR.