feat: 添加「视频保存目录」设置项

[Clouder0]

简单的例子：我在 D 盘安装该工具，但我希望将视频存放于数据盘上。

[Antonoko]

感谢反馈！这个工具是以 Portable Application（绿色软件）来设计的，相比“传统软件”，它更像是伴随着用户数据集合、放在其中一边用于辅助消费使用这些数据的小工具，无需对系统侵入式地安装、一切所需依赖都在同个文件夹下，因此设计上将用户的数据和工具文件夹包在一块视为一个整体来使用（同时其中目录下工具和数据也是分离的，工具是可以随意丢弃与更换，但用户数据永远只属于用户）—— 一个 windrecorder 文件夹就是一份记录完善的用户数据，因此会建议将整个工具文件夹放置于数据盘上。这样设计的好处是，如果你有另一个用户、或想开一份全新的 windrecoder 来记录，只需重新 git clone 与安装依赖到新文件夹就可以直接从新使用了。（移动也是如此，不过目前设计还不够完善，需要手动调整已创建的虚拟环境配置才能在新位置使用 #32

目前的设计愿景是如此，不过得益于开源特性，每个人可以按自己的理解与需求来使用这个工具。随着未来的重构优化，将可以在 config_user.json 的 record_videos_dir 中自定义存储目录。如果是出于备份需求，可以单独将 videos 文件夹下的日期子目录增量拷贝同步到其他区域，比如在 windrecoder 中设定一个较激进的超时删除时间，同时用 FreeFileSync 等工具增量备份到数据盘下，但这样做虽然存储了视频数据，也会不便于使用工具进行查询，最佳建议还是将整个 windrecorder 文件夹放置于数据盘上。

[Clouder0]

感谢反馈！这个工具是以 Portable Application（绿色软件）来设计的，相比“传统软件”，它更像是伴随着用户数据集合、放在其中一边用于辅助消费使用这些数据的小工具，无需对系统侵入式地安装、一切所需依赖都在同个文件夹下，因此设计上将用户的数据和工具文件夹包在一块视为一个整体来使用（同时其中目录下工具和数据也是分离的，工具是可以随意丢弃与更换，但用户数据永远只属于用户）—— 一个 windrecorder 文件夹就是一份记录完善的用户数据，因此会建议将整个工具文件夹放置于数据盘上。这样设计的好处是，如果你有另一个用户、或想开一份全新的 windrecoder 来记录，只需重新 git clone 与安装依赖到新文件夹就可以直接从新使用了。（移动也是如此，不过目前设计还不够完善，需要手动调整已创建的虚拟环境配置才能在新位置使用 #32

目前的设计愿景是如此，不过得益于开源特性，每个人可以按自己的理解与需求来使用这个工具。随着未来的重构优化，将可以在 config_user.json 的 record_videos_dir 中自定义存储目录。如果是出于备份需求，可以单独将 videos 文件夹下的日期子目录增量拷贝同步到其他区域，比如在 windrecoder 中设定一个较激进的超时删除时间，同时用 FreeFileSync 等工具增量备份到数据盘下，但这样做虽然存储了视频数据，也会不便于使用工具进行查询，最佳建议还是将整个 windrecorder 文件夹放置于数据盘上。

emmm，现在这样设计有什么理由吗？我可以举出一些存储分离的 use case：

1. 将本体安装在系统盘上享受 SSD 的读写速度，视频数据存放到机械硬盘上，享受低成本的存储空间。
2. 将数据存储在 NAS 挂载的网络硬盘，或者是第三方服务提供的同步盘中，在多台设备上直接共享数据。

Runtime 和 Data 分离是常规的设计思路，在实践上与 Portable 并不冲突。如果要实现「工具随时更换、数据始终保存」，把这两者分离是比较符合直觉的做法。Linux 下数据、配置和二进制文件都是分离存放的，这一点在重装系统时非常方便：我只需要从包管理器中安装二进制文件，将数据、配置文件夹直接拷贝，就能恢复原有的环境。

如果想新开一个全新的 windrecorder 记录，只需要更改对应的「数据路径」即可。这样都不需要重新安装一份完全相同的 Runtime，我觉得也是比「只需重新 git clone 与安装依赖到新文件夹就可以直接从新使用了」更方便的。

---

另外，我觉得 Python 并不是很适合做 Portable Application，作为一个依赖 Interpreter 的脚本语言，它是无法绕开环境问题的。到最后只能走向内置一个 Python Interpreter 和 Virtual Environment 的技术方案，还会遇到如 #32 中提到的小问题。

同时我也注意到，目前的项目安装依然要求用户预先安装了 ffmpeg、Git、Python、Pip，和 Portable 的设计并不是很融洽。我在初次安装的时候就对此感到疑惑。既然已经有了 Pip，为什么不直接打包上传到 PyPI 用 pip install 来安装呢？同样的，ffmpeg 为什么不直接把 binary 内置在 release package 中而要求用户手动在系统级安装呢？

所以分发思路上，两种方向：

• 点击即用的解决方案，内置 Python Interpreter、ffmpeg、Virtual Environment，让用户在无需任何前置依赖的前提下就能把软件跑起来。
• 安装式的解决方案，打包上传 PyPI、通过 pip install 一键安装。

前者是面向大众用户较好的分发方式，后者对预先已有环境的技术用户而言更为清真。

---

不过加入一个存储路径的配置项在哪种分发方式中都是正常的吧(
这也已经足够了。