Consider redesigning the configuration model

We should consider redesigning the configuration model with the main goal of simplifying usage.

The new configuration model must solve the ordering issues that exist in the current configuration model, specifically related to Filter ordering and Authorization RequestMatcher ordering.

We should also look at decoupling SecurityConfigurer references. For example, ExceptionHandlingConfigurer is referenced in multiple SecurityConfigurer's, which has resulted is various bugs overtime when minor changes are applied. However, we should also consider not using SecurityConfigurer and SecurityBuilder in the new model.

We should also explore a different approach for component configuration. Instead of using the HttpSecurity DSL, we could provide a more direct way of configuring through the use of a Customizer<SecurityConfigurer> @Bean. For example, if an application needs to customize formLogin(), it would register a Customizer<FormLoginConfigurer> @Bean. NOTE: The Customizer may receive a different type of "configuration" object instead of a SecurityConfigurer, depending how the new configuration model evolves.

Related gh-13266, gh-13057

Start by reviewing the current Filter ordering and Authorization RequestMatcher ordering, then trace the relationships among SecurityConfigurer, SecurityBuilder, ExceptionHandlingConfigurer, and HttpSecurity. Compare that model with the proposed Customizer bean approach; done would require a concrete configuration design that resolves the ordering and coupling problems described.