[RFC] Refactor the underlying model of SystemRuleManager | 重构 SystemRuleManager 底层模型

## Issue Description

Type: *feature request*

### Describe what feature you want

目前 SystemRuleManager 将所有系统规则（SystemRule）的阈值条件全部析取出来并选取最紧的阈值为最终生效的阈值，其内部并不保存原本的 SystemRule。这种实现方式会存在一些问题，比如无法记录触发的系统规则 ID，导致一些功能存在问题（如 #3138, #3084, #3019 提到的问题）。社区需要针对 SystemRuleManager 的模型进行重构，保留原始规则信息的同时又仍然符合选取同类指标最紧的阈值为最终生效的阈值。

### Additional context

在 Sentinel 最初的设计中，`SystemRule`（即系统过载保护规则）被设计为 规则：条件=1:n 的模型，即一条系统规则可包含多个系统指标条件，每个条件是 OR 的关系。例如以下 SystemRule `qps=300, highestSystemLoad=9, highestCpuUsage=0.8` 等效于三条系统规则，*分别*对应总入口 QPS 阈值为 300、系统 load 阈值为 9 以及 CPU 使用率阈值为 80% 三个独立条件。当然实际使用时（特别是控制台配置时），大家一般简化为 1:1 的模型使用。

在设计 [Sentinel Go](https://pkg.go.dev/github.com/alibaba/sentinel-golang@v1.0.4/core/system#Rule) 时，我们将该模型简化为 1:1 的模型，用 metricType（阈值类型）、启发阈值以及自适应策略类型 三个字段来代替之前平铺的指标阈值条件，以做到更加标准化。该模型也被采用在 [OpenSergo 相关 spec](https://github.com/opensergo/opensergo-specification/blob/main/specification/zh-Hans/fault-tolerance.md) 中。