[fix][feature]Default to the previous fully packaged logic, add a 'di…

[ZhaoCake]

…st-strip' option for simplified packaging.

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

[

正如在issue #10032 中所提到的，打包逻辑可能会出现问题，并且对于大部分用户而言，并不存在需要精简打包的需求。因此将默认的打包逻辑修改回原本的，另添加一个选项--dist-strip用于精简打包。

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

修改bug。

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

保留原本的完全打包逻辑作为默认打包方案，添加一个选项--dist-strip用于精简打包。
但该精简打包依赖于compile_commands.json，需要执行bear -- scons来生成这个依赖关系文件，这个在该新增选项的help当中也说明了。

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

• BSP: bsp/qemu-vexpress-a9

• action: actions

]

当前拉取/合并请求的状态 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/workflows/bsp_buildings.yml 详细请参考链接BSP自查

[ZhaoCake]

因为我今年面临考研的问题，尽管在时间上总体还比较充裕，但是为了保持时间分配的平衡，因此没有办法花太多时间，对于这个PR，我认为还存在一些可以改进的地方以及疑虑：

• 可以不使用bear工具，转而使用scons的compilationdb来生成compile_commands文件，这样就不会给用户带来额外的依赖。我在building.py中看到了相关代码，但是没有分析是如何工作的。
• 由于rtthread支持的平台很多，这导致我顾虑bear并不总是能够工作的，因为使用的编译器是不同的。
• 关于头文件的处理，原本是可以通过gcc的MM选项来得到单个目标文件的精确以来，但是同样是出于上面这个顾虑，所以我放弃了这种做法。

[BernardXiong]

因为我今年面临考研的问题，尽管在时间上总体还比较充裕，但是为了保持时间分配的平衡，因此没有办法花太多时间，对于这个PR，我认为还存在一些可以改进的地方以及疑虑：

• 可以不使用bear工具，转而使用scons的compilationdb来生成compile_commands文件，这样就不会给用户带来额外的依赖。我在building.py中看到了相关代码，但是没有分析是如何工作的。
• 由于rtthread支持的平台很多，这导致我顾虑bear并不总是能够工作的，因为使用的编译器是不同的。
• 关于头文件的处理，原本是可以通过gcc的MM选项来得到单个目标文件的精确以来，但是同样是出于上面这个顾虑，所以我放弃了这种做法。

感谢贡献 👍

由scons来生成compile_commands.json基本上应该是可行，好像有提及到可能生成不全，而再后续完善的基础上是基本可行的：scons --cdb -n -s

[supperthomas]

compile_commands.json 可以通过命令scons --cdb生产，不过路径在build中。
@BernardXiong scons --cdb 要不改成默认的吧？就直接默认生成compile_commands.json