Refactor PI function into shared library

[neko-para]

No description provided.

[neko-para]

@MistEO 有个设计上的问题感觉可以讨论一下

目前, 我整体接口的设计逻辑依然是把PI处理部分作为一个黑盒来提供; 对于使用PI库的人来说, 实际就是给PI提供一个界面前端(用来实现功能选择, 一个回调之类的)

但是这样的话, 这个库本身的价值就很有限, 并不太能用来给集成模式使用; 是不是可以看看扩展一下PI的功能, 使得集成模式依然有使用的价值? 目前我想到的是可以把创建实例部分和执行task拆开, 自己集成的情况下依然可以用PI来快速创建实例, 以及其所涉及到的用户选择部分的逻辑(而不需要集成方自己实现); 但是后续的task执行和option部分好像还是不太好复用

[neko-para]

或者就是单纯让使用PI库的一方自己去编辑config, 但感觉就比较奇怪了(或者说, 要着库有啥用啊那

[MistEO]

@MistEO 有个设计上的问题感觉可以讨论一下

目前, 我整体接口的设计逻辑依然是把PI处理部分作为一个黑盒来提供; 对于使用PI库的人来说, 实际就是给PI提供一个界面前端(用来实现功能选择, 一个回调之类的)

但是这样的话, 这个库本身的价值就很有限, 并不太能用来给集成模式使用; 是不是可以看看扩展一下PI的功能, 使得集成模式依然有使用的价值? 目前我想到的是可以把创建实例部分和执行task拆开, 自己集成的情况下依然可以用PI来快速创建实例, 以及其所涉及到的用户选择部分的逻辑(而不需要集成方自己实现); 但是后续的task执行和option部分好像还是不太好复用

主要是我们自己复用吧，比如 vscode 插件可以用、maa debugger 可以用，免得每边造一个轮子

能自己写 UI 的人我感觉也不怎么需要这么一个 config 库（

[neko-para]

那接口还是就按照 黑盒 + 输入回调 的模型来做了？目前在糊interface的解析逻辑的时候顺便把国际化做了（#244），但是这个和输入回调的相性不是很好来着（
以及，如果输入回调只是简单的提供prompt和choice，实际操作起来其实相当于限制死了ui是以若干个选择来进行的，不一定是个好主意（比如debugger里面如果想做成下拉框就很麻烦

[neko-para]

生成默认配置