add multi-monitor support

[Antonoko]

rebase #67
add #66

因为原分支距离 main 落后比较多，我将它的更改迁移到这儿来干活啦 cc @ASC8384

TODO

• 替换所有 PyAutoGUI 方法
  • 移除 pyautogui 依赖
• 实现多显示器与单显示器的录制方法
• 实现索引时的掩码后处理
• 完成 setting ux
  • crop setting
    • 屏幕比例参照
    • 多屏幕设置
  • record setting feature: h265/硬件加速 #136
    • 录制屏幕选项：仅录制某单个显示器/录制所有显示器（一期 scope）
    • 增加录制时的编码预设
  • 移除“对于「高DPI/高分辨率屏幕」,在录制时缩放至四分之一的分辨率”选项策略
• 兜底 fallback 提醒与处理，如显示器输入情况更改时
• 设置向导
• i18n
• 测试与review

[ASC8384]

收到，我这段时间接触 Mac 和 Arch 的时间远多于 Windows，进度拉下了，抱歉抱歉

[Antonoko]

收到，我这段时间接触 Mac 和 Arch 的时间远多于 Windows，进度拉下了，抱歉抱歉

言重了哥！看上去主要都完成可用了，剩下都是比较简单的和设置相关收尾工作，主要是我滴干活，哥看看代码本身有什么建议或补充就都可以了，谢谢您的贡献

[Antonoko]

其他捕获实现路径参考 （先不做，之后看看是否值得开个issue/pr) ：

https://x.com/7id/status/1771091929284894809?s=20

[Antonoko]

这里之后的commit看上去应该拆分到另一个pr，这个pr只增加多屏支持。

[ASC8384]

测试使用的两台 4K 显示器：

1. 导致使用 H.265 编码时，因为性能不足，严重影响日常使用，AV1编码勉强可以不影响；
2. 自带的两种 OCR，对于超高分辨率图片的识别性能下降得厉害；
3. 多屏阈值判断处理部分感觉还能再讨论讨论，先写了一个过渡方案。

[Antonoko]

2. 自带的两种 OCR，对于超高分辨率图片的识别性能下降得厉害；

比起更换引擎和开放接口，这个pr里我觉得可以先试试分块/分显示器识别、或者先scale down图片后再处理 等工程手段实现？（微软自带的从速度、效能、便利性、兼容性等方面来说都是比较好的首选（或者说最基本的兜底方案），paddle ocr/微信ocr等可以放到另一个pr中进行实现

[Antonoko]

已添加对ocr图像的预处理，策略为:

• 小于4000x4000的图像不进行处理；
• 大于4000x4000的图像先根据显示器分块处理，若单显示器分块后仍大于4000x4000，则对其再单独平均分块；
• 无法匹配以上情况时fallback平均分块处理，每个分块确保小于4000x4000；

在我的环境中，对于4000x4000内图片Windows media ocr仍然能保持较准确的识别结果 0 0