[REQ] ability to provide an ApiClient factory for Configuration to use when creating a new defaultApiClient

Is your feature request related to a problem? Please describe.

a mechanism for using code to customize the ApiClient lazily created by Configuration in getDefaultApiClient() would remove the need to overwrite the existing value with a custom ApiClient with auth headers, logging, and such via the request/response interceptors.

Describe the solution you'd like

the addition of a Configuration.setApiClientFactory(Supplier<ApiClient>) so that, on startup, and once auth header values have been established, all subsequent code can use Configuration.getDefaultApiClient() to retrieve the client created by this factory. also a call to setDefaultApiClient(null) will trigger a subsequent call to the factory on the next call to getDefaultApiClient() to support the use case where auth header values have changed or some other request/response interceptor behavior has changed (such as logging request and responses). obviously the factory must be invoked in a thread-safe way and only once per new-ApiClient need, which is cleanly supported by a VolatileReference MUCH better than a volatile ref. support for code currently using setDefaultApiClient() must continue to work also.

Describe alternatives you've considered

call setDefaultApiClient() after creating a customized ApiClient object that all subsequent code can retrieve via getDefaultApiClient().

Additional context

see https://github.com/OpenAPITools/openapi-generator/pull/20738

Locate the Java Configuration implementation and inspect getDefaultApiClient(), setDefaultApiClient(), and the existing ApiClient creation path. Confirm how a Supplier can be registered and invoked lazily, once per reset, while preserving direct setDefaultApiClient() behavior. Done means the factory supports updated authentication or interceptor state after resetting the default client and remains thread-safe.