Support metric-based SLIs for SLOs (not just Monitor Uptime)

Is your feature request related to a problem? Today, SLOs in OneUptime can only be built on Monitor Uptime — the SLI is always "percent of time a monitor's status was not in a bad state." There's no way to build an SLO directly from a continuous metric value (latency, error rate, or any custom reliability number), even though this is a very common way teams define SLOs elsewhere

This is a real limitation for two common, related use cases:

1. Latency/performance SLOs. Website/API monitors already support response-time-based criteria (mark a monitor Degraded/Offline above a threshold), and response time is already tracked as a metric internally. But an SLO can't be built directly against that metric — the only way to approximate a latency SLO today is to convert response time into a discrete Degraded/Offline monitor status via a criteria rule, then build an ordinary Monitor-Uptime SLO on top of that resulting status. This works, but it collapses a continuous measurement into a pass/fail gate — no p95/p99 tracking within the SLO math, no visibility into how slow, just "was it over the line or not."
2. Externally-calculated SLIs (e.g., a correctness percentage, write latency, or any custom reliability signal computed outside OneUptime). There's no way to feed a computed value directly into an SLO. The closest workaround requires two separate, uncoordinated paths: push the value in as a custom metric via OTLP (which works for dashboard visualization, but metrics don't drive alerts or SLOs), and separately send the same value to an Incoming Request monitor with a criteria rule that flips its status to Degraded/Offline past a threshold, to get alerting and an SLO via the same status-conversion trick as above. This does work, but it means computing the value once and pushing it twice, with no reconciliation between the "real number" (only visible on a dashboard tile) and the "threshold-derived status" (the only thing the SLO actually sees) — and the raw value pushed to an Incoming Request monitor doesn't appear to be retained as chartable time-series data at all, so it can't be visualized from that path either.

Both cases point at the same underlying gap: SLOs can only ever consume a monitor's discrete up/down/degraded status, never a continuous metric value directly.

Describe the solution you'd like Add a metric-based SLI option for SLOs, alongside the existing Monitor Uptime option:

• When creating or editing an SLO, allow choosing "Metric" as the SLI source (in addition to "Monitor Uptime"), and configure it with: which metric to use, a "good event" predicate/threshold (e.g., response time under 2000ms, or a custom value above 99%), and optional filters/grouping — similar in spirit to how a metric is already picked when building a Chart/Gauge widget on a Dashboard.
• Once this exists, both motivating cases are solved directly and consistently:
  • A latency SLO can be built straight from the response-time metric with a percentile/threshold predicate, with no criteria-rule/status-conversion detour needed.
  • An externally-calculated SLI pushed once (via whatever custom-metric ingestion path OneUptime already supports) becomes usable directly as an SLO's SLI, with the same value simultaneously available for dashboard charting — one ingestion path instead of two, and no lost precision.
• Error budget, burn rate, and burn-rate alerting should work the same way for metric-based SLOs as they already do for Monitor Uptime SLOs — the target %, compliance window, and budget-consumption math shouldn't need to care which kind of signal produced the underlying good/bad ratio.