#3896 Use custom int to enum mapping method for nested source property - #4146

Fixes #3896

When a custom mapping method with a primitive parameter (for example
GroupState toGroupState(int)) is used for a nested source property, the value is
extracted through a null-safe helper method that returns the boxed type (Integer).
Since #2239 the method matcher rejects a boxed source for a primitive parameter, so
the custom method was skipped and the built-in ordinal based int -> enum conversion
(GroupState.values()[state]) was used instead. That produces wrong results, or an
ArrayIndexOutOfBoundsException when the int value is not a valid ordinal.

This matches the behaviour filiphr described in the thread: the method matcher should
pick a primitive-parameter method even when the source is an object such as Integer,
and then do the null check like 1.5 did.

Changes:

• MethodMatcher can now match a boxed source type against a primitive parameter. This
  is a fall-back used only when no strict match exists, so an exact method (for example
  one taking Integer) is still preferred (keeps Autoboxing not considered when looking for a matching method #205 working).
• TypeSelector runs a strict pass first and only retries with the relaxed matching
  when the strict pass finds nothing.
• The generated invocation is guarded with a null check before unboxing, so a nullable
  source no longer causes a NullPointerException (already asserted by the existing
  NullCheckTest Null-check missing for auto-unboxing when using property mapping methods #231 case).

Added Issue3896Test in the bugs package reproducing the nested int -> enum mapping.