修复：配置变更后内核强制重启导致新内核未加载配置的问题

[byte78]

变更说明

• 调整配置变更流程，从先应用配置再重启内核，改为先重启内核再应用最新配置。
• 为 handleChangeProfile() 增加串行保护，避免 profile、脚本、DNS 等配置变化连续触发时并发执行重启和配置应用。
• 确保 updateGroups() 在配置已应用到当前内核后再读取代理组，减少代理组为空的异常日志。

问题原因

之前配置变更时会先执行 applyProfile()，将配置应用到当前内核，然后立刻执行 restartCore()。这会导致刚应用过配置的旧内核被重启，新内核未必已经加载最新配置，后续内核读取代理组时可能得到空结果，导致代理批量不可用（表现为所有节点超时）

同时，needSetupProvider 可能短时间连续变化，导致多次 handleChangeProfile() 流程交错执行，放大了这个时序问题。

[byte78]

总的来说，虽然这个 PR 修复了这个问题。但产生了 UI 上的节点列表要等待新内核应用配置后才会刷新的问题。（例如：切换订阅后，马上打开节点列表，会发现是老订阅的列表，新订阅的列表会随后加载出来。删除订阅同理，节点列表会在一定的延迟后才消失）
我觉得 Profile 发生变动 -> 强制重启内核 这个改动：
#fee9dae （优化: 更优雅的内核强制重启逻辑以及核心资源释放）
还是太暴力了。

正常来说，Profile 发生变动，以前的 applyProfile() 走 setupClashConfig() 把 profile 生成出来的完整配置下发给 core 就足够了，是不必执行重启内核这么暴力的动作的。
@appshubcc 可以解答下强制重启核心是为了解决什么问题吗？

[AIsouler]

解决什么问题

#172

如果你有更好的解决方案，欢迎提出

[byte78]

解决什么问题

#172

如果你有更好的解决方案，欢迎提出

多份配置切换后 core 内存上升是可以预期的，每份配置都含有一堆代理/规则/provider对象，这些东西加载到 core 中导致内存上升。内存上升和 core 的热加载释放机制、GC/内存归还策略有关，是上游 core 要考虑的。而且通过上面 issue 里的表现来看，不像是内存泄露问题，而是 Go 因为对象变多，对 heap 扩容，导致内存占用上升。即使后续 gc，短时间也有可能不会将内存归还给 os（特别是 os 资源还充足的情况下）

但这不应该成为 GUI 客户端强制重启 core 的动因，特别是这个行为会带来一系列副作用，例如当前版本引入的新配置没应用到新的 core 的问题，或者 IPC 通信被打断、代理列表需要等待内核重启完毕后才更新。

GUI 客户端的合理方向应该是提供“手动重启核心”的能力，而不是强制重启核心。

[appshubcc]

@byte78 虽然内核提供了重载，但是我认为切换配置重启Core这个逻辑也没啥问题，反而是为了防止潜在的问题，只是当前这个流程逻辑还需要再优化一下