Add a configurable limit for maximum nested property path depth

AbstractNestablePropertyAccessor resolves a nested property path
recursively, one recursive call per path segment, and there was
previously no limit on the nesting depth. Consequently, a sufficiently
deeply nested property path -- for example, against a self-referential
type -- could exhaust the current thread's call stack, resulting in a
StackOverflowError which lacks useful diagnostics for developers
attempting to assess what went wrong.

Note that the existing autoGrowCollectionLimit bounds array and
collection growth, not path depth.

The same is true for constructor binding via DataBinder.construct(),
which constructs a nested constructor argument recursively through a
nested property path. Path segments are constrained to declared
constructor parameters there, but a self-referential type nonetheless
permits an arbitrarily deep path.

With this commit, each property accessor tracks the number of nested
properties traversed to reach the object that it wraps, and an
InvalidPropertyException is thrown once the configured (or default)
maxNestedPathDepth limit is exceeded, with a message that reports the
configured limit. The limit applies regardless of autoGrowNestedPaths,
since resolving an existing deep object graph recurses in the same
manner as auto-growing one. Tracking the depth per property accessor
rather than threading it through the recursion allows the recursion to
dispatch through the protected
getPropertyAccessorForPropertyPath(String) method, which subclasses may
override, and avoids deriving the depth from the nested path, which
would require rescanning an ever longer path prefix at each level.

Constructor binding likewise tracks the nesting depth while
constructing nested objects as well as indexed and mapped elements, and
throws the same InvalidPropertyException once the limit is exceeded.

The maxNestedPathDepth (which defaults to 100) can be configured on a
per-use-case basis via ConfigurablePropertyAccessor or DataBinder,
which applies it to constructor binding directly and supplies it to the
property accessor via its binding result. In contrast to the auto-grow
collection limit, which is unlimited on a plain accessor, the nesting
depth is bounded by default even for programmatic property access,
since a large array or collection can be perfectly legitimate whereas a
deeply nested property path effectively never is.

Specifying zero for the maxNestedPathDepth disables support for nested
property paths altogether while continuing to allow simple, indexed,
and mapped property access, which is a reasonable way to constrain data
binding for a target object that is not intended to be traversed (such
as a flat DTO). However, negative values for maxNestedPathDepth are
always rejected.

Closes gh-37252

framework-docs/modules/ROOT/pages/core/validation/data-binding.adoc

@@ -61,7 +61,8 @@ corresponding implementation (`BeanWrapperImpl`). As quoted from the javadoc, th
 `BeanWrapper` offers functionality to set and get property values (individually or in
 bulk), get property descriptors, and query properties to determine if they are
 readable or writable. Also, the `BeanWrapper` offers support for nested properties,
-enabling the setting of properties on sub-properties to an unlimited depth. The
+enabling the setting of properties on sub-properties up to a
+<<data-binding-nested-path-depth,configurable maximum nesting depth>>. The
 `BeanWrapper` also supports the ability to add standard JavaBeans `PropertyChangeListeners`
 and `VetoableChangeListeners`, without the need for supporting code in the target class.
 Last but not least, the `BeanWrapper` provides support for setting indexed properties.
@@ -236,6 +237,48 @@ Kotlin::
 ======
 
 
+[[data-binding-nested-path-depth]]
+=== Maximum Nesting Depth for Nested Property Paths
+
+A nested property path such as `managingDirector.salary` is resolved recursively, one
+level per nested property. The nesting depth of a property path therefore corresponds to
+the number of intermediate properties that must be traversed in order to reach the final
+property -- for example, `address.country.name` has a nesting depth of 2, since the
+`address` and `country` properties must be traversed in order to reach the `name`
+property.
+
+The nesting depth of a property path cannot exceed 100 by default; however, the
+`maxNestedPathDepth` value is configurable. You can specify a custom value via
+`setMaxNestedPathDepth(...)` on a `ConfigurablePropertyAccessor` such as
+`BeanWrapperImpl`, or on a `DataBinder` -- and therefore also on a `WebDataBinder`, for
+example within an `@InitBinder` method. If a property path exceeds the configured limit,
+an `InvalidPropertyException` is thrown. Specify `0` to disable support for nested
+property paths altogether, while continuing to allow simple, indexed, and mapped property
+access -- for example, `name`, `accounts[2]`, or `accounts[KEY]`.
+
+Note that this limit applies to property binding as well as to
+<<data-binding-constructor-binding,constructor binding>> via `DataBinder.construct`,
+since a constructor parameter which is itself an object is constructed recursively
+through a nested property path.
+
+[NOTE]
+====
+Without such a limit, a sufficiently deeply nested property path can drive the recursive
+resolution of nested property paths to exhaust the current thread's call stack, resulting
+in a `StackOverflowError` instead of a descriptive exception.
+
+The `maxNestedPathDepth` limit improves diagnostics for that common case by converting
+it into a clear `InvalidPropertyException`; however, it is not a guaranteed defense against
+`StackOverflowError` under every possible JVM thread stack size configuration, since the
+amount of stack space consumed per level of nesting depends on the JVM, its JIT
+compilation state, and the platform.
+
+When binding untrusted input, you should additionally constrain binding to the expected
+input as described in
+xref:web/webmvc/mvc-data-binding.adoc#mvc-data-binding-design[Model Design].
+====
+
+
 [[data-binding-conversion]]
 == ``PropertyEditor``s