Defensively unwrap CacheConnectionFactory

This commit refines the optimization introduced in gh-39816 to only
unwrap our own caching connection factory. The more advanced unwrap
algorithm is still available, but opt-in only.

Unwrapping more aggressively may break use cases where the wrapped
ConnectionFactory is required, i.e. for transactional purposes.

Closes gh-43277

spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/messaging/jms.adoc

@@ -165,6 +165,8 @@ In most scenarios, message listener containers should be configured against the
 This way each listener container has its own connection and this gives full responsibility to it in terms of local recovery.
 The auto-configuration uses javadoc:org.springframework.boot.jms.ConnectionFactoryUnwrapper[] to unwrap the native connection factory from the auto-configured one.
 
+NOTE: The auto-configuration only unwraps `CachedConnectionFactory`.
+
 By default, the default factory is transactional.
 If you run in an infrastructure where a javadoc:org.springframework.transaction.jta.JtaTransactionManager[] is present, it is associated to the listener container by default.
 If not, the `sessionTransacted` flag is enabled.