[serial_v2] support half duplex.

[sulfurandcu]

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

[

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

使串口驱动(serial_v2)支持半双工通信。

对比用软件包的形式实现半双工通信（i.e. rt-thread-rs485），在 serial 中支持半双工通信的优势是可以更方便地在半双工口（比如rs485）上适配 console 和 ymodem 等组件。

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

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

• BSP: bsp/hc32/ev_hc32f460_lqfp100_v2

• .config: CONFIG_RT_USING_SERIAL_V2 CONFIG_BSP_UART4_RX_BUFSIZE=64 CONFIG_BSP_UART4_TX_BUFSIZE=64

• 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

[wdfk-prog]

或许可以搞个宏配置选项,是否要开启半双工?

[sulfurandcu]

目前是检查是否配置了收发切换引脚，如果没配置的话默认还是全双工通信。不过加上宏配置的话代码应该会更清晰些。

[wdfk-prog]

目前是检查是否配置了收发切换引脚，如果没配置的话默认还是全双工通信。不过加上宏配置的话代码应该会更清晰些。

我是考虑到固件大小的优化;你这样等于默认平白无故多了些大小

[sulfurandcu]

添加了 RT_SERIAL_USING_HALF_DUPLEX 宏配置

头文件中因为有RT_SERIAL_CONFIG_DEFAULT的存在，所以serial_configure结构体里面新增的dulpex相关字段没有用这个宏包起来（暂时没想到好的方法😅）

[sulfurandcu]

串口半双工通信，程序通过改变引脚电平切换到tx模式后，有可能会需要延时一段时间，来等待硬件真正地切换到发送模式，这个延时操作的实现方案，我想了以下几种，各位大佬给评估一下哪种更合适，或者有木有更好的实现方式。

[Ryan-CW-Code]

个人建议还是把半双工的控制交给用户。
如果一定要集成到驱动内部，个人感觉方案4会更好，更通用些。但是用户要知道回调函数里面能干什么，不能干什么。

[milo-9]

我建议不要在驱动里做这个事情，很多MCU的uart外设本身就有半双工功能，只需要在config里加入是否使能半双工的选项就行，如果外设不支持，那么由BSP决定是否使用软件去模拟。
我大致看了一下你这个，应该是为了应对使用485收发器这类场景吧，这种情况下，这是属于上层的事情了，驱动框架层一般是不建议用户直接使用的，在实际应用当中，往往会在驱动框架层上再包装一层，这一层就用来解决485这类场景了