feat(update): 添加新的更新通道 Nightly

[Big-Cake-jpg]

当了波丁真把疑似 IDE 瞎几把改的地方回退回去了，顺带把涉及到的文件过大的缩进改了下（

本 PR 实现了一个新的更新通道 Nightly，目的是方便高级用户第一时间体验最新的更改与 Bug 修复而无需等待下一个 Fast Ring 或 Slow Ring 版本。

锁定逻辑等与 FR 基本一致，但因 Nightly 不稳定的特性而对用户操作进行了二次确认。并且为确保遇到严重问题的用户能够第一时间获得修复，Nightly 通道强制更新（即“更新” 与 “或者更新”分别代表“确认” 与 “取消”，且均会触发更新流程）。

需要 Actions 支持，每晚对过去 24 小时的更改进行编译并打包对应架构压缩包，生成一个 nightly.json 以供启动器获取更新信息，并将资产文件上传到一个固定不变的、名为 nightly 的 pre-release。以下是一个 nightly.json 示例：

{
    "version": "2.13.4-nightly.g1a2b3c4", // 启动器的语义化版本
    "version_code": 415, // 版本代码
    "changelog": "...", // 更新日志
    "assets": [
        {
            "arch": "x64",
            "download_url": "https://r2.230225.xyz/PCL2_CE_Nightly_x64.zip",
            "sha256": "c6c371b993abec256465a50597151ad13bc08f7515f45a06fe42102b0511dc4e" // 压缩包内启动器本体的 sha256
        },
        {
            "arch": "arm64",
            "download_url": "https://r2.230225.xyz/PCL2_CE_Nightly_ARM64.zip",
            "sha256": "1da11818103323bb5e67ffecd3bf108bb4d4112c701101733d46e128d429f949" // 压缩包内启动器本体的 sha256
        }
    ]
}

由于开发经验所限，本 PR 大部分代码由 Rider 上的 Gemini Code Assist 编写。如有需要改动的地方欢迎提出，我将在空闲时间进行修改。

[ghost]

浅浅看了一眼，给点建议

Edit: 在有合适的 Exception 的情况下，应该用语义明确的 Exception 而不是更宽泛的 Exception（例如 GetAnnouncementList 应该用 InvalidOperationException）

[ruattd]

我觉得我们还是需要讨论一下是否应当限制用户自由选择更新通道，FR 之前的限制逻辑出过很多稀奇古怪的问题

这里重申一下我之前的观点：限制测试通道用户回退到更早的正式版本是合理的，但是限制测试通道用户更新到下一个正式版本是不合理的

[LingYue412]

现在需要一个配置分离的PR 作为本 PR 的前置，不然这里没法合并

[Pigeon0v0]

突然想起来，此处对 Action 的修改会不会导致和 Mirror 酱的冲突问题？现在 Mirror 酱会同步 Release 过去

[Big-Cake-jpg]

突然想起来，此处对 Action 的修改会不会导致和 Mirror 酱的冲突问题？现在 Mirror 酱会同步 Release 过去

不太了解 Mirror 酱那边的策略，如果能设置排除是否可以考虑下不同步特定 Release？

[Pigeon0v0]

不太了解 Mirror 酱那边的策略，如果能设置排除是否可以考虑下不同步特定 Release？

可能得去问问，我晚点看看吧

[Harry-hq]

不太了解 Mirror 酱那边的策略，如果能设置排除是否可以考虑下不同步特定 Release？

可能得去问问，我晚点看看吧

是不是可以换成效果类似的CI构建，实现应该会简单一点
想要Nightly的话就只更新推送每天的最后一次构建