feat: 实现 flushall async 自定义功能

[SHOWufei]

增加了以下能力：

• 支持自定义清空命令名（如重命名后的命令）；
• 支持同步/异步清空模式，异步模式下自动等待所有主节点完成内存释放（轮询 lazyfree_pending_objects，并发等待所有主节点）；
• 提供可配置的超时时间，避免无限等待，超时后 panic 退出；
• 在等待过程中输出详细的进度日志，便于监控；
• 配置文件参数化设置，便于使用；

具体改动说明

- internal/config/config.go
  ├─ 新增字段 FlushAllCommand, FlushAllMode, FlushAllAsyncTimeout (支持自定义清空命令、模式和超时)

- internal/writer/redis_cluster_writer.go
  ├─ 新增方法 GetAddresses() (返回所有主节点地址列表)

- cmd/redis-shake/main.go
  ├─ 新增函数 parseLazyfreePending() (解析 INFO memory 中的 lazyfree_pending_objects)
  ├─ 新增函数 waitAsyncFlushForNode() (单节点轮询等待，2秒间隔，支持超时)
  ├─ 新增函数 waitAsyncFlushForCluster() (并发等待所有主节点)
  ├─ 主流程调整: 提前调用 theWriter.StartWrite() 启动后台协程
  ├─ 主流程调整: 新增 redisWriterOpts 变量保存目标端配置
  ├─ 主流程调整: 重写 empty_db_before_sync 逻辑，根据配置发送自定义清空命令，异步模式下调用等待函数
  └─ 主流程调整: 删除原重复的 theWriter.StartWrite() 调用

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[suxb201]

1. 感觉不是一个刚需功能，手动 flushall 会更可靠。
2. 通常而言 flushall async 即可，没有理由需要 flushall sync，也不需要等待 flushall async 结束
3. 不需要新增一个 README 文档

[SHOWufei]

1. 感觉不是一个刚需功能，手动 flushall 会更可靠。
2. 通常而言 flushall async 即可，没有理由需要 flushall sync，也不需要等待 flushall async 结束
3. 不需要新增一个 README 文档

@suxb201 感谢您的审阅和反馈！我理解您的顾虑，以下是我的一些补充说明：

1. 关于“不是刚需”
   在手动运维场景下，执行 FLUSHALL ASYNC 确实足够，但在自动化数据迁移/同步工具（比如 RedisShake 本身）中，我们希望做到“全自动、无人值守”，如果工具只发送 FLUSHALL ASYNC 而不等待后台释放完成，紧接着就开始写入新数据，可能会遇到两个问题：

   • 数据残留与逻辑混乱：FLUSHALL ASYNC 命令的异步特性意味着它仅删除命令发起时已存在的键，在后台清理期间创建的新键会被保留，这会导致一个不“干净”的状态：新旧数据并存，给数据一致性校验和业务逻辑带来巨大隐患；
   • 迁移工具基于“empty_db_before_sync = true目标库为空”的假设也将不再成立，可能导致同步过程出现不可预知的错误；
   • 还有就是生产环境通过 rename-command 重命名了 FLUSHALL，所有才有了针对官方参数 empty_db_before_sync = true 后的兼容改造，新增了 flushall_command、flushall_mode、flushall_async_timeout三个参数；

2. 关于“不需要等待 flushall async 结束”

   • 对于普通业务，异步清空确实无需等待；
   • 但在 RedisShake 的 empty_db_before_sync 场景下，我们的目标是清空后立即开始全量同步，如果不等待，同步过程可能写入大量新数据，而旧数据还在后台渐进释放，这不仅增加了内存压力，也可能拖慢同步速度；
   • 提供可选的等待机制，可以在“速度优先”和“稳定优先”之间做选择；
   • sync 只是作为一个备选项，兼容某些不允许异步清空的 Redis 版本；

3. 关于 README 文档
   您说得对，新增一个独立 README 会增加维护负担，我稍后会：

   • 删除 README_FLUSHALL_CUSTOM.md；
   • 将必要参数说明合并到原有的配置文档（shake.toml 的注释或项目主 README 中）；

另外，本次改造在不破坏原有功能的前提下，当 empty_db_before_sync = true 时，为 RedisShake 增加了灵活的清空控制能力，确保同步开始前目标端处于干净状态。

再次感谢您的审阅，期待您的进一步指导！