Feature/tool parallel execution

[lyw405]

引入 toolGrouping.ts 模块，实现智能工具调用分组策略，在保证执行正确性的前提下最大化并行度，显著提升性能。

关键特性

三类工具分类：安全并行工具（只读）、文件写入工具（冲突检测）、全局副作用工具（强制串行）
智能文件冲突检测：通过路径标准化和访问跟踪，确保同一文件的多次写入按顺序执行
读写分离：只读操作聚合并行，写入操作根据文件依赖智能分组
安全保障：全局副作用工具（bash、todowrite）和 MCP 工具完全隔离执行

性能提升

多个只读操作（read/grep/ls）并行执行
不同文件的写入操作（write/edit）可在同一组内并行
避免不必要的串行等待，减少总执行时间

// 输入: [read(a), read(b), write(c), write(d), write(c)]
// 分组:
// Group 1: [read(a), read(b)]      - 并行执行
// Group 2: [write(c), write(d)]    - 并行执行（不同文件）
// Group 3: [write(c)]              - 串行执行（保证顺序）

[sorrycc]

感谢 pr！我最早的时候也想做并行的 tool 调用，但是先放着了是出于两个考虑，1）会增加复杂度，2）read/ls 等操作的性能相比 llms 调用来说并不是瓶颈。

所以这个 pr 会先 hold，等到有需要解这块性能问题时才考虑合并。

如果你有相关的明显的前后对比数据，也可以补充一下。

[lyw405]

感谢 pr！我最早的时候也想做并行的 tool 调用，但是先放着了是出于两个考虑，1）会增加复杂度，2）read/ls 等操作的性能相比 llms 调用来说并不是瓶颈。

所以这个 pr 会先 hold，等到有需要解这块性能问题时才考虑合并。

如果你有相关的明显的前后对比数据，也可以补充一下。

这两个考虑完全赞同。

1. 复杂度问题我有考虑到，对于该部分内容也特地单独的放到了toolGrouping.ts。
2. 这种并行策略对于小项目小文件价值相对低一些，对于大项目且有比较多的大文件的价值就会凸显，这个后面如果有相关的性能问题再优化也可。

在实现这个优化之前，我观察到LLM 不太喜欢同时调用多个工具，例如：“查看当前文件夹(例如有10个文件)下有哪些文件”，那么大概率会进入单独查看的循环中，而不是一次返回10个工具调用依次执行，所以提示词需要考虑优化。