Consider requireFactor for AuthorizationManagerFactories

Related to https://github.com/spring-projects/spring-security/issues/18004

Currently, to specify a time-sensitive factor, it is needed to create an AuthorizationManagerFactory by way of a static factory that returns a builder:

var passwordIn30m = AuthorizationManagerFactories.multiFactor()
		.requireFactor( (factor) -> factor
			.passwordAuthority()
			.validDuration(Duration.ofMinutes(30))
		)
		.build();

This can then be used to create rules that include this factor as a basis:

http
		.authorizeHttpRequests((authorize) -> authorize
			.requestMatchers("/admin/**").access(passwordIn30m.hasRole("ADMIN"))
			.anyRequest().authenticated()
		)
		// ...

When just one factor is under consideration, this boilerplate could be reduced in a few ways. One way is to make it simpler to provide just one authority like so:

var passwordIn30m = AuthorizationManagerFactories.hasFactor(PASSWORD_AUTHORITY, Duration.ofMinutes(30));
http
		.authorizeHttpRequests((authorize) -> authorize
			.requestMatchers("/admin/**").access(passwordIn30m.hasRole("ADMIN"))
			.anyRequest().authenticated()
		)
		// ...

Or, AuthorizationManagerFactories could expose the individual authorities:

var passwordIn30m = AuthorizationManagerFactories.hasPasswordFactor((f) -> f.validDuration(Duration.ofMinutes(30)));
http
		.authorizeHttpRequests((authorize) -> authorize
			.requestMatchers("/admin/**").access(passwordIn30m.hasRole("ADMIN"))
			.anyRequest().authenticated()
		)
		// ...

I like the idea of having a simpler representation for a single factor since there are use cases other than multi-factor authentication when applications will want to require a time-sensitive factor in order to proceed.

NOTE: This ticket is marked as team-attention since we don't have a clear idea whether to go down any of these routes just yet.

Start with AuthorizationManagerFactories and read the related issue #18004 to understand the existing multi-factor factory and the unresolved alternatives. The work is not ready for implementation until the team chooses a single-factor API direction; done would mean implementing and validating that agreed design.