[pin][5.0.0] 修正pin框架数据类型使用不当

[ZosCat1]

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

[

STM32

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

[修改pin数据类型]

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

[修改pin数据类型]

在什么测试环境下测试通过 (what is the test environment)

]

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

[Guozhanxin]

有没有什么好处，没好处的话，这么改，感觉没必要。

1. 解决了什么问题？
2. 兼容性，向前兼容，向后兼容？

[mysterywolf]

解决了数据类型混乱的问题，历史问题。5.0.0不考虑向前兼容性。但是本修改对前向兼容影响不大，都是本仓库自己内部的问题。

[Guozhanxin]

解决了数据类型混乱的问题，历史问题。5.0.0不考虑向前兼容性。但是本修改对前向兼容影响不大，都是本仓库自己内部的问题。

数据类型混乱是什么问题？会造成什么后果吗？

[mysterywolf]

问题主要为：

1. pin的数据类型有些采用uint16 有些使用rt_bsse_t, 还有些采用int16_t，这个之前和你讨论过，应该统一为rt_base_t，因为有些bsp是按照顺序排下来的，还有一些是采用位域的方式处理的比如英飞凌。
2. 部分变量使用的数据类型明显超过其所需，例如enabled变量使用的是一个rt_uint32_t，但是这个变量只需要存储enable/disable二值即可，结果搞了个32位的整形。
   修改均是一些非重大影响，但是看起来非常难受的问题。影响到sensor框架重构。