项目代码结构调整和可配置化方案

[AzideCupric]

Core 的职责

Core 是 Bison 的功能核心，可以认为是 Bison 业务功能的最小代码抽象集合，定义各个模块的行为约束和扩展接口，以及执行扩展的加载。Core 外的代码为其具体功能的实现和内置的扩展集合。

Core包含如下模块：

模块	功能	配置形式
schedule	负责 site 下 target 的调度	模式
platform	同一平台下 site 的聚合，定义行为约束的实现接口	路径
post	报文，site 被调度后最终产出的标准格式结果	模式
site	target 所属的站点，确定这一类 target 统一的报文获取行为	路径
subsio	提供数据在外部和Bison之间迁移的接口	路径
theme	提供 post 如何转换为最终的展示效果的渲染实现接口	路径
send	提供渲染后post结果的发送接口	模式

上述模块的具体实现则在core目录外编写。

Non-Core 模块

除了上述提到的模块，剩余模块认为是 Bison 非核心功能模块，不在 core 目录下出现，而是直接实现。

模块	描述
webui	web管理页面静态文件目录以及api定义
config	配置读取和整合
cli	命令行管理命令定义
utils	工具函数集合
compat	兼容函数定义（或许应该变成 utils.compat）
database	数据库操作函数封装
types	类型定义
bootstrap	启动时需要执行的操作

Core 的可配置化

可配置化的目的是使得用户可以通过一个配置文件定义大部分Bison的功能。
这一方案可以通过 Bison在启动时读取配置文件，将其加载到 Core 下各个模块中的 config 实现。
不过这会脱离 nonebot 现有的 env 配置方案。
但保留现有env配置选项是完全没问题的，可以作为一种快捷路径存在。
需要在 config 模块中处理两边的优先级与合并。
某些模块需要实现在其模块扩展中获取扩展对应配置的分发逻辑

模块的配置会存在以下情形：

• 模式：存在多个行为，运行时只选择其一
• 路径：存在多个行为，运行时不同数据通过配置进行抉择

[felinae98]

site/platform 统一放到 /source 里吧