Exclude logback-classic from generate-configprops plugin dependency

[ryanjbaxter]

Summary

Fixes intermittent/reproducible failures of the generate-configprops exec-maven-plugin execution in downstream projects (e.g. spring-cloud-config's 5.0.x CI: https://github.com/spring-cloud/spring-cloud-config/actions/runs/35267039454/job/105356701618):

java.lang.NoSuchMethodError: 'java.lang.ClassLoader ch.qos.logback.core.util.Loader.systemClassloaderIfNull(java.lang.ClassLoader)'

spring-cloud-build-docs is consumed by this execution via the jar-with-dependencies classifier — a shaded uber jar that already bundles its own, self-consistent logback-classic/logback-core pair. However, exec-maven-plugin's includePluginDependencies classpath merge also separately resolves the dependency's own unversioned logback-classic (which lands on an old, incompatible version), adding a second, conflicting copy of these classes to the classpath. Which copy actually gets loaded for which class depends on classpath ordering, which isn't guaranteed stable across builds — hence the intermittent nature of the failure.

Verified by disassembling the actual jars from a failing CI run: the uber jar's bundled Loader class has systemClassloaderIfNull, but the separately-resolved standalone logback-core (an old version) does not, while the separately-resolved logback-classic's ContextInitializer doesn't call it at all — confirming two mismatched copies were present on the classpath.

Fix

Exclude ch.qos.logback:logback-classic (which transitively pulls logback-core) from the spring-cloud-build-docs plugin dependency declaration in the generate-configprops execution, so the classpath relies solely on the matched pair already bundled in the uber jar.

Test plan

• CI passes for this PR
• spring-cloud-config's 5.0.x CI job (which triggered this investigation) is rerun against the updated spring-cloud-build snapshot and passes the generate-configprops step consistently