Do not recursively try to reset configuration properties for library types

[ryanjbaxter]

Fixes #1698

PR #1680 (released in 5.0.2) added logic to ConfigurationPropertiesRebinder that resets a @ConfigurationProperties bean's fields to their class-level defaults during a rebind, so that properties removed from the Environment don't retain stale values. For nested, non-simple property values it recurses:

  else if (value != null && defaultValue != null && !BeanUtils.isSimpleValueType(value.getClass())) {                                                                                                    
      resetProperties(value, defaultValue);                                                                                                                                                              
  }  

This recursion had no cycle detection and no restriction on which types it descended into. When a @ConfigurationProperties bean exposes a field of a JDK or library type the reset walks that type's internal object graph. SSLContext's graph is cyclic, so the recursion never terminates and throws StackOverflowError during rebind.

The recursion is now bounded and restricted to types it makes sense to reset (user-defined nested configuration properties), with a configurable escape hatch:

1. Cycle guard. resetProperties now threads an identity-based visited set (Collections.newSetFromMap(new IdentityHashMap<>())). Revisiting an instance short-circuits, guaranteeing the recursion always terminates
2. Skip JDK types (by class loader)
3. Skip standard API namespaces. Becausejakarta.* and legacy javax.* API types are loaded by the application class loader, the class-loader check above does not catch them.
4. Configurable exclusions. For library types that are neither JDK nor standard-API, a new property spring.cloud.refresh.never-reset-nested-types accepts a comma-separated list of fully qualified class names or package prefixes to additionally skip