Handle Prometheus API without /api/v1/status/config endpoint (e.g. Thanos)

[filippog]

This is a followup issue from #573.

Currently pint will fail checks that require Prometheus configuration to work e.g. promql/rate, for example when running pint against a Thanos cluster.

There's several approaches to this problem, each with their own trade offs, including:

1. warn the user something is amiss
2. disable the checks that require access to Prometheus configuration
3. synthesize the required Prometheus configuration in pint configuration

[zerodayyy]

I've got a similar issue when running Pint against VictoriaMetrics. It doesn't provide some Prometheus API endpoints like Thanos, leading to similar errors.

[hagen1778]

@zerodayyy if pint uses /api/v1/status/config call only to get scrape_interval value for rate validation, then it makes not much sense for VictoriaMetrics due to the following reasons:

1. VictoriaMetrics doesn't need to correct too low look-behind window for rate expressions, as it does it automatically during evaluation. See https://www.percona.com/blog/better-prometheus-rate-function-with-victoriametrics/ and https://docs.victoriametrics.com/metricsql
2. VictoriaMetrics is usually used as centralized storage for many collectors. The data can be scraped with different scrape_intervals, the data can be pushed with custom resolution. So it could be that global scrape_interval just doesn't make sense, since various metrics could have different resolution.

Btw, Prometheus can also have jobs with custom scrape intervals. Does pint account for this by checking to which job metrics selector in the expression belongs?