Fail fast when spring-security-access is missing

[jyx-07]

Summary

Fixes #19441.

spring-security-config's deprecated legacy method-security support throws a raw NoClassDefFoundError at startup instead of a clear error when spring-security-access isn't on the classpath.

Root cause

#17847 moved MethodSecurityMetadataSourceAdvisor and MethodSecurityInterceptor from spring-security-core (a mandatory dependency of spring-security-config) into the new spring-security-access module, which spring-security-config only depends on optionally. Several deprecated method-security paths still construct these types unconditionally:

• GlobalMethodSecuritySelector → MethodSecurityMetadataSourceAdvisorRegistrar (proxy mode) and GlobalMethodSecurityConfiguration (imported for both proxy and aspectj mode)
• ReactiveMethodSecuritySelector → ReactiveMethodSecurityConfiguration (@EnableReactiveMethodSecurity(useAuthorizationManager = false))

@EnableMethodSecurity and @EnableReactiveMethodSecurity's default mode — the non-deprecated replacements — never reference these classes and are unaffected.

Fix

Added a ClassUtils.isPresent(...) guard (the same pattern already used for other optional dependencies in these selectors) so the legacy paths fail fast with a clear IllegalStateException naming the missing dependency, instead of a NoClassDefFoundError deep in Spring's configuration-processing machinery.

Chose this over making spring-security-access mandatory again, since that would silently reintroduce the footprint #17847 removed for the majority of apps using @EnableMethodSecurity. @EnableGlobalMethodSecurity stays deprecated; this adds no new investment in it beyond a clear diagnostic.

Testing

Added Gh19441Tests, using the existing @ClassPathExclusions harness to simulate spring-security-access being absent:

• @EnableMethodSecurity and @EnableReactiveMethodSecurity default mode start cleanly (locks in that the modern paths are unaffected).
• @EnableGlobalMethodSecurity in proxy mode, aspectj mode, and @EnableReactiveMethodSecurity(useAuthorizationManager = false) all now fail with the clear message instead of NoClassDefFoundError/ClassNotFoundException.

Full spring-security-config suite passes (3640 tests; the only 3 failures are pre-existing, locale-related, and unrelated to this change). ./gradlew :spring-security-config:check passes.

[jzheaux]

Thanks for the contribution, @jyx-07!

Note I've rebased this onto 7.0.x since I've confirmed the bug there as well.

Regarding the solution, the IllegalStateException is an improvement, thank you. I've adjusted the PR to place the checks closer to the problematic code itself. The reason is that the boolean logic originally proposed was missing a check for jsr250Enabled, something else that also requires spring-security-access — which is a hint that we should reuse the existing boolean logic instead of replicating it. I've also removed the comment, since moving the behavior into a separate method makes the code self-documenting. I also moved the ClassUtils check in order to play nicely with Framework's AOT support. I also added a test for jsr250Enabled to make sure we have that covered.

[jzheaux]

Thanks, @jyx-07, for the PR! This is now merged into 7.0.x and main and will go out in the next release.