Fix/legacy modpack null type

[fatelove42]

概述

修复了由于旧版本 HMCL 或第三方工具导出的整合包配置文件 modpack.cfg 中缺失 type 字段，导致在最新版本 HMCL 中更新整合包时抛出 IllegalArgumentException 或 JsonParseException 并中断更新的问题。

---

根本原因

1. JSON 反序列化校验限制：先前 ModpackConfiguration.validate() 强制要求 type 字段不能为 null。在解析缺乏 "type" 键的旧版 modpack.cfg 时，校验失败导致反序列化抛出异常并落空。
2. 未判空的类型断言拦截：CurseInstallTask 及其他整合包安装任务在比对提供商类型时没有检查 type 是否为 null。在旧配置中 type 为 null 时，!"Curse".equals(null) 被计算为 true，从而误判并抛出 IllegalArgumentException（“Instance is not a CurseForge modpack. Cannot update this instance.”）。

---

主要修改

1. 放宽 ModpackConfiguration.validate()：移除了 ModpackConfiguration.validate() 中对 type == null 的强行抛错限制，允许旧版本整合包配置成功反序列化。
2. 安全的提供商类型校验：在所有整合包 installer 任务（包括 CurseInstallTask、ModrinthInstallTask、McbbsModpackLocalInstallTask、McbbsModpackRemoteInstallTask、MultiMCModpackInstallTask、ServerModpackLocalInstallTask、ServerModpackRemoteInstallTask）中增加了 config.getType() != null 的前置检查。只有当 type 存在且明确与当前提供商不匹配时才抛出异常拦截；老整合包（type == null）将顺畅放行并在更新完成后自动写回包含 type 的规范新配置。

[3gf8jv4dv]

维护者已经开始猜疑有 AI 特征的 PR 了：#6598

不过我先帮作者解释一下：

1. 标题看起来是 PR 的分支名，没有编辑导致的
2. 作者之前在 HMCL 的 GitHub 有交流记录：https://github.com/HMCL-dev/HMCL/issues?q=sort%3Aupdated-desc%20involves%3Afatelove42