Potential banner.txt conflicts and VersionExtractor optimization in Spring Cloud Stream 4.3.0

Describe the issue

Derived of this issue, In Spring Cloud Stream 4.3.0 (included in Spring Cloud 2025.0.0), a banner.txt file was added as a resource in the default location where Spring Boot searches for application banners. This creates two potential issues:

1. Banner Location Conflict: When applications have their own banner.txt file in the default location (src/main/resources/), there's unpredictable behavior regarding which banner is displayed at startup. The ClassLoader may find either the Spring Cloud Stream banner or the application's banner first, making the outcome non-deterministic.

2. Unnecessary Performance Impact: The VersionExtractor EnvironmentPostProcessor always scans JARs to extract and set the spring-cloud-function.version system property for display in the Spring Cloud Stream banner, even when applications want to use their custom banner and don't need this version information.

To Reproduce

1. Create a Spring Boot application with Spring Cloud Stream 4.3.0+ dependency
2. Add a custom banner.txt file in src/main/resources/ (default location)
3. Run the application
4. Observe non-deterministic behavior: sometimes the Spring Cloud Stream banner appears, sometimes the custom banner appears

Version of the framework

• Spring Boot: 3.5.6
• Spring Cloud: 2025.0.0
• Spring Cloud Stream: 4.3.0

Expected behavior

1. Banner Predictability: Applications should have control over which banner is displayed, or there should be a clear precedence order that doesn't rely on ClassLoader order.

2. Optional Version Processing: There should be a configuration property to disable the VersionExtractor processing when applications don't need the spring-cloud-function.version system property, avoiding unnecessary JAR scanning and potential startup performance penalties.

Your considerations in this regard will be greatly appreciated! Thank you!