Fixes #4060

Problem

When updating an existing bean with NullValuePropertyMappingStrategy.SET_TO_DEFAULT, MapStruct resets a null source property by creating a fresh default instance via the parameterless constructor (new Target()). For target property types that do not expose an accessible no-args constructor (e.g. LocalDate, LocalDateTime, Instant, BigDecimal, BigInteger, Comparable), this generated uncompilable code such as:

target.setLocalDate( new LocalDate() );

As requested in the issue, MapStruct should report a compilation error during annotation processing rather than emitting code that fails to compile.

Change

• Type#hasAccessibleParameterlessConstructor() — new helper that returns true only when new Type() would actually compile (an implicit default constructor, or a declared non-private no-args constructor). Unlike the existing hasAccessibleConstructor(), it returns false for types that only expose parameterized constructors (e.g. BigDecimal).
• PropertyMapping#assignToPlainViaSetter(...) — for the SET_TO_DEFAULT case, when the default instance would be built through a parameterless constructor (no factory/builder) and the target type lacks an accessible one, report GENERAL_NO_SUITABLE_CONSTRUCTOR (the message referenced in the issue). Types that are initialized differently — those with an implementation type (collections/maps), arrays, Optional, or a sensible default — are intentionally excluded.

Test evidence

Added org.mapstruct.ap.test.bugs._4060.Issue4060Test:

• setToDefaultWithoutParameterlessConstructorFails — asserts the expected compilation errors for LocalDate, BigDecimal and Comparable<String>.
• setToDefaultWithParameterlessConstructorResetsToNewInstance — verifies the existing reset-to-new-instance behaviour still works for constructible types.

Local run (JDK toolchain, processor module):

• Issue4060Test — 4 tests, 0 failures.
• Related regression tests pass: Issue1790Test, Issue3884Test, JSpecifySafetyGuardTest, NullValuePropertyMappingTest, NullValuePropertyMappingClearTest.
• checkstyle:check on the processor module passes.

Verification done

1. No in-flight PR (gh pr list --search for 4060 / SET_TO_DEFAULT constructor) and no self-claim comments on the issue.
2. Fix touches .java files only.
3. Reproduced the bug against main (453602e): without the change the erroneous mapper compiles and emits new LocalDate(); with the change the documented compilation error is raised.
4. No parent epic — issue is standalone and labelled bug, hack.commit.push.