Helidon 4.x 日志依赖管理优化：移除核心模块对Logback的依赖声明

背景与现状分析

在Helidon微服务框架的当前版本中，核心模块的dependencies/pom.xml文件包含了与Logback日志实现相关的依赖管理配置。然而经过架构分析发现，Helidon核心组件本身并不直接依赖Logback实现，这种依赖声明实际上是为示例项目（如logging-slf4j示例）提供的。

这种设计存在两个主要问题：

1. 职责分离不清晰：核心框架不应强制携带特定日志实现的依赖管理
2. 版本耦合风险：用户项目可能无意中继承Helidon管理的Logback版本

技术影响评估

此次变更涉及以下技术层面：

1. 依赖管理机制：Maven的dependencyManagement会影响所有子模块的版本解析
2. 向后兼容性：可能影响依赖Helidon版本管理的现有项目
3. 原生镜像支持：SLF4J模块中仍会保留Logback相关的Native Image配置（仅以字符串形式引用）

解决方案设计

核心改动

1. 从helidon-dependencies模块中移除Logback相关配置
2. 在示例工程中显式声明Logback依赖
3. 保留SLF4J的Native Image配置（因其不产生实际依赖）

版本策略建议

考虑到可能影响现有用户，建议在4.x的minor版本中实施此变更，因为：

• 不涉及API签名变化
• 仅影响依赖解析机制
• 用户可通过显式声明Logback版本来规避问题

开发者迁移指南

对于不同场景的开发者：

示例项目维护者

需要在自己的pom.xml中显式添加：

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>${logback.version}</version>
</dependency>

生产项目开发者

如果项目依赖Helidon的版本管理：

1. 评估是否使用Logback
2. 如使用，需添加显式依赖声明
3. 考虑锁定特定Logback版本

架构优化价值

此项调整将带来以下长期收益：

1. 更清晰的职责边界：核心框架只管理必需依赖
2. 更灵活的日志选择：用户可自由选择日志实现版本
3. 更小的依赖树：减少不必要的传递依赖
4. 更好的模块化：为未来日志模块的进一步解耦奠定基础

后续演进方向

建议后续可考虑：

1. 提供标准的日志适配器SPI
2. 完善各日志实现的Native Image支持文档
3. 在Helidon Starter中增加日志实现选项