tools: harden target generator serialization

[yanhu7150-tech]

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

[

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

本 PR 修复 tools/targets 目录下多个目标工程生成器在序列化路径、宏定义、编译参数、链接参数以及工程文件字段时存在的不一致问题。
tools/targets 中的生成器用于根据 RT-Thread 工程信息生成 CMake、Makefile、VSCode、SES、Xmake、Zig、Eclipse、Visual Studio、VS2012、Keil、IAR、CodeBlocks、CDK、ESP-IDF 等工程或构建文件。修复前，不同生成器分别在各自文件中手工拼接宏定义、include path、source path、library path、linker script、XML 属性、CMake list、Lua / Zig 字符串等内容，导致同一类输入在不同生成器中处理结果不一致，部分合法输入会被错误序列化，从而生成语法错误或语义错误的工程文件。
本 PR 修复的问题主要包括以下几类：

1. 宏定义序列化不一致
   SCons 中常见的宏定义形式包括：
   • "FOO"
   • "FOO=1"
   • ("FOO", "1")
   • ["FOO", "1"]
     其中 ("FOO", "1") 和 ["FOO", "1"] 的语义应当是 FOO=1。修复前，部分生成器会将 tuple / list 形式的带值宏错误拆分为两个独立项，例如生成 FOO;1、-DFOO -D1，或者只保留值而丢失宏名，导致生成的工程文件宏定义语义错误。
2. 使用 set() 去重导致顺序不稳定
   修复前，部分生成器使用 set() 对宏定义、include path、source path 或 library path 去重。该方式会打乱原始顺序，导致生成文件内容不稳定，也可能改变 include path、library path 或宏定义的优先级。对于工程生成器来说，顺序稳定性很重要，因此本 PR 改为顺序稳定的去重方式。
3. 路径和字符串缺少目标格式转义
   不同工程文件格式对特殊字符的处理规则不同。修复前，多个生成器直接拼接字符串，路径或宏定义中包含空格、分号、引号、反斜杠、#、$、XML 特殊字符等内容时，可能生成错误文件。例如：
   • CMake list 中的空格、分号、引号、反斜杠需要正确处理；
   • Makefile 中的空格、#、$ 等字符需要正确处理；
   • Lua / Xmake 字符串中的引号和反斜杠需要正确处理；
   • Zig 字符串中的引号和反斜杠需要正确处理；
   • XML 属性中的 &、<、>、引号等字符需要正确处理；
   • IDE 工程文件中以分号分隔的 include path / define list 需要保持稳定语义。
4. VSCode 生成器对 compile_commands.json 的解析不健壮
   tools/targets/vsc.py 修复前对 command 字符串使用简单 .split() 解析。对于带空格的 include path，例如 -I"dir with space/inc"，该方式会错误拆分路径，导致 VSCode workspace 的 include path 不完整或错误。
   此外，空 compile_commands.json 会导致空目录树访问 list(...)[0]，触发 IndexError。
5. VSCode 生成器中存在不必要的 eval() 去重逻辑
   修复前，vsc.py 中通过 str() + eval() 对列表项去重。该方式不够稳健，也不适合处理包含特殊字符的数据结构。本 PR 将其替换为顺序稳定的普通去重逻辑。
6. SES / CodeBlocks 等生成器存在 Python 3 兼容性问题
   例如：
   • tools/targets/ses.py 使用 Python 2 风格的 file()，在 Python 3 下会触发 NameError；
   • tools/targets/codeblocks.py 中存在对 Python 3 str 调用 .decode() 的情况，会触发 AttributeError；
   • 文本模式下直接写入 ElementTree.tostring(..., encoding='utf-8') 返回的 bytes，可能触发 TypeError。
7. CodeBlocks 生成器宏定义处理错误
   修复前，CodeBlocks 生成器中存在遍历宏字符串字符的问题。例如对于 RT_USING_FINSH，旧逻辑可能逐字符遍历，最终只保留最后一个字符对应的错误宏选项。对于 ("STM32", "1") 这类带值宏，也可能生成错误的 -D1，丢失宏名。
8. linker script 参数解析不完整
   部分生成器对 linker script 参数的解析不完整，例如：
   • -Tfoo.lds
   • -T foo.lds
   • -T "dir with space/link.lds"
   • -Wl,-T,foo.lds
     修复前，相关逻辑可能因为简单字符串拆分或正则不完整而截断路径或漏掉 linker script 参数。
9. ESP-IDF / CMake list 中路径未正确转义
   esp_idf.py 生成 idf_component_register(SRCS ... INCLUDE_DIRS ...) 时，如果 source path 或 include path 包含空格、分号等字符，旧逻辑可能破坏 CMake list 语义。本 PR 对相关路径进行统一序列化处理。
   以上问题均属于普通工具链 / 工程生成器的软件缺陷，会影响生成项目文件的正确性、稳定性和可用性，不涉及安全漏洞。

你的解决方案是什么 (what is your solution)

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

1. 新增 tools/targets/target_utils.py
   新增公共工具模块，用于统一处理目标工程生成器中的常见序列化逻辑，包括：
   • 宏定义规范化；
   • 顺序稳定去重；
   • 路径归一化；
   • CMake 字符串和 list 序列化；
   • Makefile 字段序列化；
   • Lua / Xmake 字符串序列化；
   • Zig 字符串序列化；
   • XML 属性值序列化；
   • IDE 分号列表序列化；
   • compile command 参数拆分；
   • include path 参数提取；
   • linker script 参数解析；
   • file group 路径归一化。
2. 统一宏定义处理逻辑
   将多个生成器中分散的 CPPDEFINES / LOCAL_CPPDEFINES 拼接逻辑改为使用公共 helper。现在可以稳定处理以下形式：
   • "FOO" → FOO
   • "FOO=bar" → FOO=bar
   • ("FOO", "1") → FOO=1
   • ["FOO", "1"] → FOO=1
   • "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 / list 形式的带值宏不再被错误拆分；
   • XML 属性中的特殊字符不再破坏 XML；
   • file group 路径使用稳定的相对路径表示；
   • 路径分隔符更加稳定；
   • 保留原有工程结构，不做无关重构。
8. 修复 Zig / Xmake 生成逻辑
   • 对 include path、source path、宏定义和 flag 使用对应格式的字符串转义；
   • 修复 Zig linker script 参数解析中对 -T 相关形式处理不完整的问题；
   • 保持原有生成器结构不变，只修复序列化相关缺陷。
9. 当前 PR 不新增 testcase 文件
   本 PR 当前保留实现代码修复，不新增 tools/testcases 下的测试文件。验证方式以 Python 语法检查、diff 检查和开发过程中的边界输入验证为主，避免在本次 PR 中引入额外测试文件。

请提供验证的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 -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
git diff --check

验证结果：

python -m py_compile 执行完成，无语法错误输出。
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 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
• 如果是新增bsp, 已经添加ci检查到.github/ALL_BSP_COMPILE.json 详细请参考链接BSP自查

[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!

[yanhu7150-tech]

您好，请问这个 PR 是否还需要我补充更多验证信息或调整实现？我已经在本地完成了 Python 语法检查和回归测试，测试结果已写在 PR 描述中。谢谢。

[yanhu7150-tech]

各位维护者好，打扰了。
这个 PR 目前已经等待了几天，当前状态显示还有工作流需要维护者审批，同时也需要具有写入权限的审阅者进行 review。
如果方便的话，麻烦帮忙看一下这个 PR，或者批准一下待运行的工作流。
感谢！

[yanhu7150-tech]

各位维护者好，打扰了。
这个PR目前已经等待了几天，当前状态显示还有工作流维护者呵，同时也需要具有读取权限的审阅者进行审核。
如果方便，麻烦看一下这个PR
谢谢啦！