优化候选窗重复显示与定位更新

[revaraver]

做了什么

这次主要减少候选窗在输入过程中的重复 UI 操作：

• 候选窗已经显示时，不再重复调用 ShowWindow(SW_SHOWNA)；
• 候选窗已经隐藏时，不再重复调用 ShowWindow(SW_HIDE)；
• 候选窗最终位置没有变化时，不再重复调用 SetWindowPos；
• 保留原有自动隐藏 timer 的清理逻辑，尽量不改变现有行为。

解决的问题

在一些长期运行的宿主程序里，比如 Chrome，用小狼毫输入时，候选窗出现会逐渐变得有明显阻尼感。

本地排查发现，慢点不在 librime 取候选结果，而主要在候选窗 UI 的显示、更新和定位路径上。宿主窗口运行时间长了以后，重复 ShowWindow / SetWindowPos 的开销会被放大，导致按键后候选窗出来得慢。

这个改动就是跳过明显没有必要的重复窗口状态更新，降低每次输入触发的 UI 开销。

本地对比

在本地带插桩版本中，对 Chrome 里已经变卡的窗口和修复后的新窗口做过对比，核心路径大概是：

• show 平均耗时：24.08ms -> 2.58ms
• cand_update 平均耗时：22.45ms -> 3.98ms
• CandidateList.UpdateInputPosition 平均耗时：25.41ms -> 11.74ms
• UpdateComposition 平均耗时：99.60ms -> 35.18ms

体感上，候选窗弹出的阻尼明显下降。

说明

这不是改输入逻辑，也不改候选生成逻辑，只是减少候选窗层面的重复窗口操作。

[revaraver]

补充几个相关 issue，主要是为了解决小狼毫输入法存在已久的输入卡顿/候选窗响应迟缓问题：

• 輸入法在Chrome使用一段時間會卡頓 #1413
• Windows小狼毫输入法异常卡顿 home#1894
• 关于一部分weasel的用户卡顿的原因和改进建议 #1250

其中 #1413 里有不少用户提到 Chrome / Edge 使用一段时间后输入变慢、候选框出现有明显延迟；也有人提到把 tab 拖到新窗口后会恢复流畅。这个现象和我本地排查到的情况比较一致：卡顿更像是跟着宿主窗口状态走，而不是候选生成本身慢。

这次改动主要是减少候选窗层面的重复 ShowWindow / SetWindowPos 调用，目标就是缓解这类长期存在的“小狼毫输入时候选窗响应变慢”的问题。