[Feature]: 针对不同平台分别配置 API、模型、URL 等参数

### Class | 类型

程序主体

### Feature Request | 功能请求

目前，硅基流动、阿里云、腾讯云等平台都提供了 deepseek API，但各自的模型命名方式不一致：
- 硅基流动：`deepseek-ai/DeepSeek-R1`、`Pro/deepseek-ai/DeepSeek-R1`
- 百度云、腾讯云、阿里云：`deepseek-r1, deepseek-v3`
- Deepseek 官方：`deepseek-reasoner, deepseek-chat`

由于模型命名方式不一致，当前配置文件只能调用 `deepseek-reasoner`，无法兼容 `deepseek-r1` 或 `deepseek-ai/DeepSeek-R1` 等名称。
比如我试图调用腾讯平台的 deepseek-r1，会返回“很抱歉，模型 'deepseek-r1' 暂不支持”

为解决这个问题，我建议基于不同平台配置模型，例如：

```
# URL 兼容 OpenAI 格式，省略后面的 v1/chat/completions
use_models = [
{
"platform": "deepseek",
"model": "deepseek-reasoner, deepseek-chat, deepseek-coder",
"URL": "https://api.deepseek.com",
"API_KEY": "xxxx",
"USE_PROXY": False
},
{
"platform": "tencent",
"model": "deepseek-r1, deepseek-v3, hunyuan-turbo",
"URL": "https://api.lkeap.cloud.tencent.com/v1/",
"API_KEY": "xxxx",
"USE_PROXY": False
},
{
"platform": "siliconflow",
"model": "deepseek-ai/DeepSeek-R1, Pro/deepseek-ai/DeepSeek-R1, deepseek-ai/DeepSeek-V3",
"URL": "https://api.siliconflow.cn",
"API_KEY": "xxxx",
"USE_PROXY": False
}
]
```

这样，如果某平台兼容 OpenAI 的 API 调用，用户只需在配置文件中添加相应的平台名称、地址和模型即可，不必限制于内置的 `AVAIL_LLM_MODELS` 列表。
大部分国内平台都兼容 OpenAI 的 URL 调用方式，除了ChatGPT, Google等API，大部分已经不需要在设置 `API_URL_REDIRECT` 。

当需要同时调用多个平台或模型时，可以考虑类似
`MULTI_QUERY_LLM_MODELS = "siliconflow-deepseek-ai/DeepSeek-R1"&"tencent-deepseek-r1"` 的方式，即通过多段字符指定平台和模型。
另外，`EMBEDDING_MODEL` 也可用类似如上的格式配置，以调用不同平台的 embedding 模型，而不仅限于默认的 OpenAI 的`text-embedding-3-small`， 比如可以替换为通义的 text-embedding-v2 。
比如专门列一个：
```
{
"platform": "aliyun",
"embedding_model": "text-embedding-v2, text-embedding-v3",
"URL": "https://dashscope.aliyuncs.com/compatible-mode",
"API_KEY": "xxxx",
"USE_PROXY": False
}
```

或许 `gpt_academic` 最初可能是针对 ChatGPT 而设计，如果以上修改以兼容多个国内平台和模型涉及较大改动，可以忽略本建议。
以上建议的原因就是原来的逻辑是通过模型的名字去匹配对应的API和URL，而没有预料到同一个模型可以在不同的平台（URL）调用，并且同一个模型可能在不同的平台名称也不一样。

之所以提出此需求，是因为国内 deepseek 官方平台目前并不稳定，使用第三方平台的deepseek往往更可靠。
通过以上配置方式，也便于用户使用在某个平台拥堵时，切换不同平台的并继续使用同一个模型。

如果不会增加过多开发成本，还请予以支持。

谢谢。

Start by locating the configuration and code paths for AVAIL_LLM_MODELS, API_URL_REDIRECT, MULTI_QUERY_LLM_MODELS, and EMBEDDING_MODEL. Compare how model names currently select APIs and URLs, then define the per-platform configuration behavior and verify that multiple providers and embedding models can be selected without the built-in model list.

Written by the indexing model from the issue text.