[bsp/cvitek] Update packaging method

[flyingcys]

Use pre-build files to reduce compilation time

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

[

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

修改cvitek 打包方式为预编译文件

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

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

[supperthomas]

ci好加吗？

[unicornx]

关于这个打包的 issue，我以前建过一个 #9060 ，用于讨论 solution 和可行性。
但我最新的想法是不倾向于增加 prebuild。原因分析具体见 #9060 (comment)。后来也就没有继续这个工作了。

如果大家觉得引入 prebuild 的做法可以继续，那我也没有意见（这个 pr 我也看了，按这个思路做的改动本身没有什么大的问题），只是个人觉得这不是个好的 solution。

Anyway，其实对于一些 feature 的开发，我的建议是先建立 issue ，充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。

谁可以决定这个事情呢？可以拍个板。

[BernardXiong]

关于这个打包的 issue，我以前建过一个 #9060 ，用于讨论 solution 和可行性。 但我最新的想法是不倾向于增加 prebuild。原因分析具体见 #9060 (comment)。后来也就没有继续这个工作了。

如果大家觉得引入 prebuild 的做法可以继续，那我也没有意见（这个 pr 我也看了，按这个思路做的改动本身没有什么大的问题），只是个人觉得这不是个好的 solution。

Anyway，其实对于一些 feature 的开发，我的建议是先建立 issue ，充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。

谁可以决定这个事情呢？可以拍个板。

建立 issue ，充分讨论后再开发和 pr。 确实是一个正确的模式，可惜开源社区迭代可以更快速些，如果有更好的方式，后续也可以再推翻来过 😮‍💨

[flyingcys]

ci好加吗？

CI已经添加一个

[flyingcys]

关于这个打包的 issue，我以前建过一个 #9060 ，用于讨论 solution 和可行性。 但我最新的想法是不倾向于增加 prebuild。原因分析具体见 #9060 (comment)。后来也就没有继续这个工作了。

如果大家觉得引入 prebuild 的做法可以继续，那我也没有意见（这个 pr 我也看了，按这个思路做的改动本身没有什么大的问题），只是个人觉得这不是个好的 solution。

Anyway，其实对于一些 feature 的开发，我的建议是先建立 issue ，充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。

谁可以决定这个事情呢？可以拍个板。

当前pre-build 增加文件大小为2.9M空间。
之前也是因为有人提出在线下载并编译很浪费时间，也对网络有较大依赖，所以才修改为 pre-build方式。