tools: harden target generator serialization

[yanhu7150-tech]

拉取/合并请求描述：(PR description)

为什么提交这份PR (why to submit this PR)

本 PR 修复 tools/targets 目录下多个工程生成器在序列化路径、宏定义、编译参数和项目文件字段时存在的不一致问题。

这些工具用于根据 RT-Thread 工程信息生成 CMake、Makefile、VSCode、SES、Xmake、Zig、Eclipse、Visual Studio、Keil、IAR、CodeBlocks、CDK、ESP-IDF 等工程或构建文件。修复前，不同生成器分别在各自文件中手工拼接路径、宏定义、编译选项、XML 属性、CMake list、Lua/Zig 字符串等内容，导致一些合法输入在生成目标工程文件时被错误序列化，进而生成不可用或语义错误的项目文件。

本 PR 修复的主要问题包括：

1. CPPDEFINES / LOCAL_CPPDEFINES 中带值宏处理不一致
   例如 SCons 中常见的宏定义形式 ("FOO", "1")，其语义应为 FOO=1。旧代码中部分生成器会将 tuple 宏错误展开为两个独立项，例如输出为 FOO;1、-DFOO -D1，或者在 XML / IDE 工程字段中产生错误宏定义。

2. 部分生成器使用 set() 对路径或宏定义去重
   这会打乱原始顺序，导致生成文件内容不稳定，也可能改变原有 include path、define 或 library path 的优先级。

3. 路径、宏和 flag 缺少面向目标格式的转义
   不同工程文件格式对特殊字符的处理规则不同，例如：

   • CMake list 中的空格、分号、引号、反斜杠；
   • Makefile 中的空格、#、$；
   • Lua / Xmake 字符串中的引号和反斜杠；
   • Zig 字符串中的引号和反斜杠；
   • XML 属性中的 &、<、>、引号等字符；
   • IDE 工程文件中的分号分隔列表。

   旧代码中多个生成器直接字符串拼接，路径或宏中包含空格、分号、引号等字符时，可能生成语法错误或语义错误的工程文件。

4. VSCode 生成器对 compile_commands.json 的解析不健壮
   tools/targets/vsc.py 旧代码对 command 字符串直接使用 .split()，会错误拆分 -I"dir with space" 这类带空格的 include 路径。同时，空 compile_commands.json 会导致空目录树访问 list(...)[0]，触发 IndexError。

5. VSCode 生成器中存在不必要的 eval() 去重逻辑
   旧代码通过 str() + eval() 对列表项去重，不够稳健，也不适合处理包含特殊字符的数据结构。本 PR 改为顺序稳定的去重逻辑。

6. SES / CodeBlocks 等生成器存在 Python 3 兼容性问题
   例如：

   • tools/targets/ses.py 使用 Python 2 风格的 file()，Python 3 下会直接 NameError；
   • tools/targets/codeblocks.py 中存在对 str 调用 .decode() 的情况，Python 3 下会触发 AttributeError；
   • 文本模式下写入 ElementTree.tostring(..., encoding='utf-8') 返回的 bytes，可能触发 TypeError。

7. CodeBlocks 生成器宏定义序列化错误
   旧代码会遍历宏字符串中的每一个字符，例如 RT_USING_FINSH 可能最终只输出最后一个字符对应的宏选项；tuple 宏 ("STM32", "1") 也可能丢失宏名，仅保留错误的值项。

8. Eclipse / Zig / ESP-IDF 等生成器中 linker script 或 CMake list 解析不完整
   例如 -T "dir with space/link.lds"、-Tfoo.lds、-Wl,-T,foo.lds 等 linker script 参数形式，旧逻辑可能因简单 split 或正则不完整而截断路径。ESP-IDF 生成的 idf_component_register(SRCS ... INCLUDE_DIRS ...) 中，路径如果包含空格或分号，也可能破坏 CMake list 语义。

以上问题均属于普通工具链/工程生成器的软件缺陷，会影响生成项目文件的正确性和可用性，不涉及安全漏洞。

解决方案是什么

本 PR 引入公共序列化辅助模块，并将多个目标工程生成器中分散的手工拼接逻辑统一收敛到可复用的 helper 中，减少各生成器重复实现导致的不一致问题。

主要修改如下：

1. 新增 tools/targets/target_utils.py

   新增公共序列化 helper，用于统一处理：

   • 宏定义规范化；
   • 顺序稳定去重；
   • 路径规范化；
   • CMake list / string 转义；
   • Makefile 字段转义；
   • Lua / Xmake 字符串转义；
   • Zig 字符串转义；
   • XML 属性转义；
   • IDE 分号列表序列化；
   • compile command 参数拆分；
   • include 参数提取；
   • linker script flag 解析；
   • file group 路径归一化。

2. 统一宏定义处理

   将多个生成器中分散的 CPPDEFINES / LOCAL_CPPDEFINES 拼接逻辑改为使用公共 helper。现在支持以下形式：

   • "FOO" → FOO
   • ("FOO", "1") → FOO=1
   • ["FOO", "1"] → FOO=1
   • "FOO=bar" → FOO=bar
   • "FOO=\"a b\"" → 保持带值宏语义

   同时避免使用 set() 打乱宏定义顺序。

3. 修复 CMake / ESP-IDF 相关生成逻辑

   对 CMake / ESP-IDF 生成器中的 source path、include path、library path、宏定义和相关 list 项进行面向 CMake 的安全序列化，避免空格、分号、引号等字符破坏 CMake list 语义。

4. 修复 Makefile 生成逻辑

   对 Makefile 中的 DEFINES、CPPPATHS、SRC_FILES、LIBS、LIBPATHS 等字段进行 Makefile 语义下的转义，同时尽量保留 $(BSP_ROOT) / $(RTT_ROOT) 等已有 Make 变量语义。

5. 修复 VSCode 生成逻辑

   • 使用更可靠的 command split 逻辑解析 compile_commands.json；
   • 支持 -Ifoo、-I foo、/Ifoo、/I foo 等 include 参数形式；
   • 正确处理带空格的 quoted include path；
   • 空 compile_commands.json 不再触发 IndexError；
   • 移除 eval() 去重逻辑，改为顺序稳定的去重实现。

6. 修复 SES / CodeBlocks Python 3 兼容性问题

   • 将 Python 2 风格的 file() 替换为 Python 3 可用的 open()；
   • 修正文本模式写 bytes 的问题；
   • 移除 Python 3 下无效的 .decode() 调用；
   • 保证 XML 输出可被正常解析。

7. 修复 XML / IDE 工程生成器中的路径和属性序列化

   对 Eclipse、Visual Studio、VS2012、Keil、IAR、CodeBlocks、CDK 等生成器中涉及 XML 属性、文件路径、include path、define list 的逻辑进行同主题修复：

   • tuple 宏不再被错误拆分；
   • XML 属性中的特殊字符不再破坏 XML；
   • file group 路径使用稳定的相对路径表示；
   • 路径分隔符更加稳定；
   • 保留原有工程结构，不做无关重构。

8. 修复 Zig / Xmake 生成逻辑

   • 对 include path、source path、宏定义和 flag 使用对应格式的字符串转义；
   • 修复 Zig linker script 参数解析中对 -T 相关形式处理不完整的问题；
   • 保持原有生成器结构不变，只修复序列化相关缺陷。

9. 新增回归测试

   新增 tools/testcases/test_target_serialization.py，覆盖以下场景：

   • normalize_defines 对字符串宏、tuple 宏、带值宏和 quoted value 的处理；
   • 顺序稳定去重；
   • CMake / Makefile / Lua / Zig / XML 字符串转义；
   • linker script flag 解析；
   • VSCode 空 compile_commands.json；
   • VSCode quoted include path；
   • VSCode arguments 数组和 -I 分离写法；
   • SES Python 3 生成不崩溃；
   • CodeBlocks 宏定义不再逐字符截断；
   • CodeBlocks XML 输出可解析；
   • CDK tuple define 不再崩溃；
   • ESP-IDF CMake 路径包含空格时可正确序列化；
   • Keil / VS / VS2012 / IAR 等生成器中 tuple define 保持 FOO=1 语义。

请提供验证的bsp和config (provide the config and bsp)

• BSP: N/A

本 PR 修改的是 tools/targets 下的 Python 工程生成器和对应回归测试，不涉及具体 BSP 源码修改。

• .config: N/A

本 PR 不需要修改任何 BSP .config 选项。

• action: N/A

本 PR 已在本地完成 Python 语法检查、单元测试和 diff 检查。提交 PR 后，可继续以 GitHub Actions 的结果为准。

本地验证命令如下：

python tools\testcases\test_target_serialization.py
python -m unittest discover -s tools\testcases -p "test_target_serialization.py"
python -m py_compile tools\targets\target_utils.py tools\targets\vsc.py tools\targets\ses.py tools\targets\cmake.py tools\targets\makefile.py tools\targets\xmake.py tools\targets\zigbuild.py tools\targets\eclipse.py tools\targets\vs.py tools\targets\vs2012.py tools\targets\keil.py tools\targets\iar.py tools\targets\codeblocks.py tools\targets\cdk.py tools\targets\esp_idf.py tools\testcases\test_target_serialization.py
git diff --check

本地测试结果如下：

Ran 23 tests

OK

本地 diff 检查结果：

git diff --check

无 whitespace error。

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 代码是高质量的 Code in this PR is of high quality
• 已经使用[formatting](https://github.com/mysterywolf/formatting) 等源码格式化工具确保格式符合[RT-Thread代码规范](https://github.com/RT-Thread/rt-thread/blob/master/documentation/contribution_guide/coding_style_cn.md) This PR complies with [RT-Thread code specification](https://github.com/RT-Thread/rt-thread/blob/master/documentation/contribution_guide/coding_style_en.md)
• 如果是新增bsp, 已经添加ci检查到[.github/ALL_BSP_COMPILE.json](https://github.com/RT-Thread/rt-thread/blob/master/.github/ALL_BSP_COMPILE.json) 详细请参考链接[BSP自查](https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/development-guide/bsp-selfcheck/bsp_selfcheck)

[github-actions]

👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread!

为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。
To ensure your code complies with RT-Thread's coding style, please run the code formatting workflow by following the steps below (If the formatting of CI fails to run).

---

🛠 操作步骤 | Steps

1. 前往 Actions 页面 | Go to the Actions page
   点击进入工作流 → | Click to open workflow →

2. 点击 Run workflow | Click Run workflow

• 设置需排除的文件/目录（目录请以"/"结尾）
  Set files/directories to exclude (directories should end with "/")
• 将目标分支设置为 \ Set the target branch to：bugfix-target-generator-serialization
• 设置PR number为 \ Set the PR number to：11557

3. 等待工作流完成 | Wait for the workflow to complete
   格式化后的代码将自动推送至你的分支。
   The formatted code will be automatically pushed to your branch.

完成后，提交将自动更新至 bugfix-target-generator-serialization 分支，关联的 Pull Request 也会同步更新。
Once completed, commits will be pushed to the bugfix-target-generator-serialization branch automatically, and the related Pull Request will be updated.

如有问题欢迎联系我们，再次感谢您的贡献！💐
If you have any questions, feel free to reach out. Thanks again for your contribution!