[RFC][doxygen]Doxygen comment standard processing

[1078249029]

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

[

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

根据#10046，标准化doxygen文档编写流程

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

目前doxygen文档编写流程还不成熟，遇到如下问题：

1. 对于宏较多的情况是否新建group来更好的组织宏？
2. 如何编写components/drivers下的测试用例？persudo device的方案是否可行？有无更好方案？
3. 编写组件的markdown时是否应该与官方中文文档对应？英文文档是否与此同步？中文的图片如何英文化？

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

• BSP:

• .config:

• action:

]

当前拉取/合并请求的状态 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自查

[supperthomas]

ci路径加一下

[supperthomas]

https://github.com/RT-Thread/rt-thread/blob/master/.github%2Fworkflows%2Fdoxygen.yml#L20-L28

[supperthomas]

https://github.com/RT-Thread/rt-thread/blob/master/.github%2Fworkflows%2Fdoxygen.yml#L20-L28

路径加一下，触发ci看效果

[supperthomas]

[supperthomas]

下面的push: 路径也加一下

[unicornx]

@1078249029 以后提交 PR 时能将我添加为这些 doxygen 相关 PR 的审阅者吗？

另外我看这个 PR 是标记为 RFC 的，所以我理解还是 draft 阶段，如果不想理解被 merge，github 支持标记为 draft pr，参考 https://docs.github.com/zh/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests

[unicornx]

我建议优先把 https://rt-thread.github.io/rt-thread/page_device_framework.html 相关的 API 的注释整理好，譬如 rt_device_find/rt_device_init 这些。否则你会发现 markdown 中有很多地方都在反复的写 rt_device_find 的注释，譬如 https://rt-thread.github.io/rt-thread/page_device_framework.html#autotoc_md254 和 https://rt-thread.github.io/rt-thread/page_device_audio.html#autotoc_md799。
而且如我们在 #9824 (comment) 的 （4） 中总结的那样，这些有关形如 rt_device_find 的注释应该直接引用源文件中的 doxgen 注释，无需在 markdown 文件中重复描述。

这部分描述我添加到 #9424 (comment) 中了，备忘。

[unicornx]

@1078249029 我补充了一些问题，不过由于这个 pr 已经被 merge了，所以我提了一个 issue：#10065，请看一下。

[unicornx]

此外，我发现这个 PR 的 title 和 pr 的内容描述写得也是让人很迷惑，这个 pr 就是针对 driver/audio 的注释修改而已，感觉和 pr 的描述毫无关系。因为已经 merge 了看起来无法修改，建议以后 pr 时注意。

@1078249029 @supperthomas FYI。

[1078249029]

我建议优先把 https://rt-thread.github.io/rt-thread/page_device_framework.html 相关的 API 的注释整理好，譬如 rt_device_find/rt_device_init 这些。否则你会发现 markdown 中有很多地方都在反复的写 rt_device_find 的注释，譬如 https://rt-thread.github.io/rt-thread/page_device_framework.html#autotoc_md254 和 https://rt-thread.github.io/rt-thread/page_device_audio.html#autotoc_md799。 而且如我们在 #9824 (comment) 的 （4） 中总结的那样，这些有关形如 rt_device_find 的注释应该直接引用源文件中的 doxgen 注释，无需在 markdown 文件中重复描述。

这部分描述我添加到 #9424 (comment) 中了，备忘。

@unicornx 这部分我会在完成audio注释内容后统一整理

[1078249029]

此外，我发现这个 PR 的 title 和 pr 的内容描述写得也是让人很迷惑，这个 pr 就是针对 driver/audio 的注释修改而已，感觉和 pr 的描述毫无关系。因为已经 merge 了看起来无法修改，建议以后 pr 时注意。

@1078249029 @supperthomas FYI。

@unicornx 我当时想的是用audio注释的编写作为整个doxygen文档编写的标准化流程，无论是之后的utest测试代码的编写还是当前的doxygen文档。没想到先被合并了。
之后在提交utest的部分我也会以RFC的形式提交的。