Consider nested property paths when filtering Querydsl parameters.

[lovrovrlec]

Fixes the regression reported in #2579.

Since GH-2572, filterByJacksonVisibility matches each request parameter against a flat map of
top-level Jackson field names. A nested key such as address.street is never a key in that map, so
it is dropped and the endpoint silently degrades to findAll — a filtered request returns every row.
Nested paths are otherwise fully supported: QuerydslPredicateBuilder resolves them via
bindings.getPropertyPath(...), and they worked up to 5.0.5.

This resolves parameter names segment by segment, translating each segment through its own
MappedJacksonProperties so @JsonProperty renames keep working at depth, and rejecting the whole
parameter as soon as a segment is not exposed — extending the GH-2572 guarantee to nested paths
instead of weakening it.

Two tests, added in the first commit so the regression is visible on its own:

• forwardsNestedPropertyPathsToQuerydsl fails before the fix (the parameter never reaches Querydsl).
• doesNotExposeJsonIgnoredPropertiesNestedInAssociations passes before the fix only vacuously, and
  fails against a naive fix that forwards dotted keys unchecked — it pins the security property.

One deliberate decision worth your input: when a segment's owning type has no MappedJacksonProperties
(e.g. a map value), visibility cannot be established, so the parameter is rejected. This is stricter
than pre-5.0.5 behaviour, where such paths were forwarded and left to Querydsl's binding resolution to
reject. Happy to switch to forwarding them if you prefer the lenient variant.

[lovrovrlec]

@christophstrobl could you take a look at this when you next triage? It fixes a regression from GH-2572 (3dc76b8), reported in #2579.