feat: Add automatic retries for transient Postgrest errors

[thagikura]

What kind of change does this PR introduce?

Feature

Closes #1243

What is the current behavior?

All Postgrest requests fail immediately on transient errors (HTTP 503/520, network failures) with no retry
mechanism. This is problematic for intermittent infrastructure issues where a retry would succeed.

What is the new behavior?

Idempotent requests (GET, HEAD) are automatically retried with exponential backoff on transient errors:

• Retries on HTTP 503 (Service Unavailable) and 520 (Unknown Error)
• Retries on network errors (connection failures, timeouts)
• Exponential backoff: 1s, 2s, 4s delays (max 30s)
• Default max 3 retries, configurable via Postgrest.Config.maxRetries
• Per-query opt-out via noRetry() in the request builder
• x-retry-count header sent on retried requests
• Non-idempotent methods (POST, PATCH, DELETE) are never retried

// Retries enabled by default for GET requests
val result = supabase.from("messages").select()

// Disable retries for a specific query
val result = supabase.from("messages").select {
    noRetry()
}

// Configure max retries globally
install(Postgrest) {
    maxRetries = 5  // default is 3
}

Additional context

Matches the retry behavior in supabase-js (PR supabase/supabase-js#2072). The retry logic catches both
RestException (for retryable HTTP status codes) and HttpRequestException (for network errors) since they
represent different failure modes in the supabase-kt HTTP stack.

[thagikura]

228d293
@jan-tennert thanks. Addressed in the commit.