Revisit Management context AOT support to not require the contributor to be a bean

ChildManagementContextInitializer is a bean that implements BeanRegistrationAotProcessor and isn't a BeanPostProcessor. The intention with AOT is that BPP replaces their runtime behavior and BeanRegistrationAotProcessor isn't really meant to be implemented on a regular bean directly.

While querying a bean itself for its state at build-time is something that's inevitable, I think it would make more sense for the actual processor to be more static. For instance, such registration could react to the presence of ManagementContextFactory and replaces it.

The generated code looks like this:

  /**
   * Use AOT management context initialization
   */
  private static ChildManagementContextInitializer childManagementContextInitializerAddManagementInitializer(
      RegisteredBean registeredBean, ChildManagementContextInitializer instance) {
    return instance.withApplicationContextInitializer(new com.example.actuator.webmvc.mgmtport.ActuatorWebMvcMgmtPortApplication__ManagementApplicationContextInitializer());
  }

Rather than doing this, it could replace ManagementContextFactory with a static version that knows the ApplicationContext type to create and the reference to the generated initializer. The current arrangement is such that ManagementContextFactory is still created regularly, but its state contains everything that has been resolved at build-time using code generation (typically the configuration class to use).

Start by reading ChildManagementContextInitializer and ManagementContextFactory, then trace how the BeanRegistrationAotProcessor contributes to the generated code shown in the issue. The intended result is to revisit this arrangement so the contributor does not need to be a regular bean and the build-time-resolved state is represented by a more static processor.