Refactor/monorepo

[NWYLZW]

🤔 这个 PR 的性质是？

• 日常 bug 修复
• 新特性提交
• 文档改进
• 演示代码改进
• 组件样式/交互改进
• CI/CD 改进
• 重构
• 代码风格优化
• 测试用例
• 分支合并
• 其他

🔗 相关 Issue

💡 需求背景和解决方案

monorepo 支持。

📝 更新日志

• 本条 PR 不需要纳入 Changelog

☑️ 请求合并前的自查清单

⚠️ 请自检并全部勾选全部选项。⚠️

• 文档已补充或无须补充
• 代码演示已提供或无须提供
• TypeScript 定义已补充或无须补充
• Changelog 已提供或无须提供

[NWYLZW]

一、渐进式迁移。先把整体挪到 monorepo 下面，保证能够运行起来；再依次将各个模块拆出来，分别独立作为单一模块进行发布与依赖管理。
二、common 模块的迁移动作。由于 common 模块的特殊性，我们需要保证 common 的迁移成本尽可能的小，我决定把它作为最后一步来进行。
三、关于类型 tsconfig 的规整化。现有 tsconfig 相对较为混乱，我们需要定义一套可用的 monorepo 的中每一种文件的类型定义。保证相互之前不产生冲突。
四、文档站的迁移。这个需要往后面挪，和构建流程产生一定的依赖关系，需要处理清晰才能正确进行。
五、单元测试的适配。目前单元测试针对于单仓过于依赖，需要改造文件路径的匹配规则。
六、构建流程的调整。如果按照第一步的整体挪动，展示只会涉及到文件路径的变动，调整一下编译发布目标即可。按照后续的模块拆解来看的话，我们需要一个根据依赖关系逐层编译产物。

[github-actions]

[uyarn]

七、CI的调整 目前特别是发布流程利用了git tag 改成Mono Repo后 这部分也要考虑