Feature: Support NPM package as plugin dependency

[Hieuzest]

Describe the problem related to the feature request

为插件的可选功能提供可选的NPM package依赖
因为这个包比较大，不太适合作为默认依赖来自动安装

Describe the solution you'd like

1. 支持使用 market/新的插件 来管理(Add)环境中的pacakges
2. 允许插件在p.j中声明可选依赖并以一定流程添加进环境
3. （Optional）官方支持的模块动态导入范式，以处理相关的副作用

Describe alternatives you've considered

一个稍弱的方案是，通过官方支持的pacakge name pattern（如@npm/foobar) 在market和loader中进行重定向

Additional context

No response

[shigma]

可选依赖可以写进 peerDepdendencies。

[Hieuzest]

需要一个在用户侧将其加入环境的流程。给每个包单独发插件是不合理的。

[ilharp]

给每个包单独发插件是不合理的。

给每个包单独发插件是合理的，这样可以使用户对自己所安装的依赖有足够的掌控。允许用户自行管理依赖将会需求用户同时对自己的插件树和依赖树均有足够的了解，这将极大地增加用户在使用 Koishi 时的心智负担。

具体地，用户将会需要在进行依赖管理时考虑如下问题：

• 这个依赖是什么？有何作用？
• 有哪个插件正在使用它吗？
• 移除这个依赖会使某个插件的部分功能不可用？还是所有功能不可用？还是会导致 Koishi 无法启动？

意义不明的依赖将会使用户对依赖管理这个操作失去整体的自信，进而失去对自己实例的了解和掌控，使实例维持在「能跑就行」的状态，增加了后续的管理成本和依赖链隐患。相比之下，将依赖封装为服务插件将会使用户保持通过插件管理 Koishi 实例功能的状态，用户可以在插件配置页面配置插件树及插件可用性，同时可以在此页面看到项目主页、使用方法（usage 导出）和依赖的服务插件，从而可以自信地管理自己的实例。

特别地，如果你并不面向控制台用户发行插件，那么请直接在插件的 README 中介绍依赖的管理方法。

[shigma]

需要一个在用户侧将其加入环境的流程。给每个包单独发插件是不合理的。

我不太同意楼上的观点，我认为增加手动安装其他 peerDependency 的流程具有一定的意义。但尽管如此，考虑到插件市场现有的 800 个插件并没有体现出需要此项功能，我个人认为这个需求的优先度属于「极低」范畴。由于 Koishi 团队岌岌可危的产能，在可见的未来，如果有人需要这个能力我都会建议发 peerDependency。