Add response caching for read-only API calls

[sentry-junior]

Summary

The CLI should cache API responses to avoid redundant network calls and improve perceived performance, especially in interactive and iterative workflows. This was identified as a top usability concern after real-world usage.

Analysis

• Current behavior: every command hits the Sentry API with no caching layer.
• Gap: repeated invocations (e.g. listing issues, browsing events) re-fetch identical data, adding latency and unnecessary load.
• Direction: implement a local response cache (e.g. TTL-based, keyed on URL + query params) with a reasonable default TTL; expose --no-cache / --refresh flags to bypass.
• Scope: read-only endpoints only (GET); mutations must never be cached.

Concerns

• Cache invalidation strategy: time-based TTL is simplest; consider shorter TTLs for high-churn data like issues vs. longer for events/traces.
• Cache storage: filesystem (e.g. ~/.cache/sentry-cli/) preferred over in-memory for persistence across invocations.