优化 Kuikly 模板工程的宏观架构：聚合多端目录与支持 Ktor 服务端集成

[BobcGn]

近期在使用 Android Studio 创建 Kuikly 模板工程时，我将其与最新版的 JetBrains 官方 KMP (Kotlin Multiplatform) 模板进行了对比。
Kuikly 的模板在跨平台覆盖面上极具前瞻性（特别是对鸿蒙、小程序和 H5 的支持），这极大地拓宽了 Kotlin 跨平台的应用边界。但在工程的整体架构组织上，随着支持平台的增多，我们可以借鉴最新官方模板的一些结构规范，以便更好地承载复杂的大型项目，让开发者在开发初期就能建立清晰的全局视野。
为此，我提出以下两点架构层面的优化建议：

1. 通过统一的 app 目录收敛多端入口，提升工程架构清晰度
   • 当前痛点：目前 Kuikly 模板会在工程根目录下平铺各个平台的入口模块（如 androidApp, iosApp, ohosApp, miniApp 等）。随着生态平台的增加，根目录的模块数量会迅速膨胀，导致工程结构显得较为发散和臃肿。
   • 期望改进：参考最新官方 KMP 模板的结构（见截图），建议在根目录下创建一个统一的 app 目录，将所有端侧的宿主工程模块以及 shared 模块聚合到该目录之下。
   • 架构价值：这种收敛式的设计能赋予项目更好的“大局观”（Big Picture）。项目的根目录可以保持清爽，专门留给构建脚本、CI/CD 配置、底层通用核心库或服务端模块。这能帮助开发者从更高的架构视角去管理复杂的跨平台项目，而非一上来就陷入各个端侧模块的细节中。
2. 在模板层面支持 Ktor 服务端工程的集成
   • 当前痛点：目前的 Kuikly AS 模板主要聚焦于大前端 UI 层的跨平台展示，缺少对后端服务的联动支持。
   • 期望改进：如最新官方 KMP 向导所示，其工程结构中已经标准地集成了 server（Ktor）目录。建议 Kuikly 的模板工具也能跟进，提供包含 Ktor 服务端的全栈工程骨架（作为可选 Checkbox 或独立的 Full-stack 模板）。
   • 架构价值：打通从底层接口、后端数据服务到多端一致性 UI 的全链路 Kotlin 体系。这将极大提升那些希望从零开始构建高可靠性、全栈闭环项目的开发者的体验。

附件
• 图片：最新版 JetBrains 官方 KMP 模板的目录结构展示：

希望能与社区共同探讨这些架构改进的可行性。感谢 Kuikly 团队持续的开源贡献！