Call API: Expose Response Headers in Action Output

Extend the Call API action so builders can read and use HTTP response headers in their app logic, not just the response body and status code.

## Summary
Currently, the Call API action only exposes the **Response Body** and **Status Code** as outputs. Many APIs rely on HTTP response headers to deliver important metadata, such as pagination cursors, rate limit info, auth/refresh tokens, or custom application signals. Without access to headers, builders cannot fully integrate with these APIs using Call API alone and must resort to workarounds or external tooling (e.g. Make, Zapier, etc).

## Current Problem
- The Call API action returns:
- Response Body
- Status Code
- It does **not** expose:
- Response Headers (e.g., `Location`, `Link`, `X-RateLimit-Remaining`, `X-Next-Page`, `Set-Cookie`, etc.)
- As a result:
- Builders cannot read pagination cursors or continuation tokens that are only sent in headers.
- Apps cannot react to rate limit or quota information from headers.
- Any flows that depend on header-based data (e.g., auth flows, custom metadata) are blocked or require non-native workarounds.
## Examples/Scenarios
- **Pagination cursors:**
An API returns the next page cursor in a header like `X-Next-Page`. The app needs this value to fetch the next page of results, but it’s inaccessible via Call API today.
- **Rate limiting:**
The API returns rate limit info (`X-RateLimit-Remaining`, `X-RateLimit-Reset`) in headers so the client can throttle or inform the user — but the app cannot see those values.
- **Redirects or resource locations:**
A POST request creates a resource and returns the new resource URL in the `Location` header. The app can’t easily capture and store that URL.
- **Auth / token management:**
Some APIs return refreshed tokens in headers (e.g., `Set-Cookie`, `X-Auth-Token`). Without header access, automated token refresh flows are not possible with Call API alone.
- **Custom app metadata:**
Third-party APIs may use custom headers (`X-*`) to indicate things like internal IDs, state flags, or security info required for subsequent calls.
## Why This Matters
- **Unlocks more APIs**: Many modern APIs rely on headers for critical metadata. Exposing headers makes Glide’s Call API action more robust and compatible.
- **Reduces workarounds**: Avoids the need for proxy servers or external middleware just to capture and forward headers into Glide.
- **Better UX & reliability**: Apps can handle rate limits, pagination, and auth flows more gracefully, improving end-user experience.
- **Aligns with developer expectations**: Most HTTP client libraries expose headers and body together. Bringing Glide in line with this makes the platform feel more complete and professional.
## Suggested UX
- **New output field in Call API configuration:**
- Add a “Response Headers” section to the Call API result settings.
- This could be:
- A **JSON object** containing all headers (key-value pairs), or
- A dedicated **collection of “Header Name → Value” pairs**.
- **Header selection & mapping:**
- Allow builders to:
- Store the full headers object in a JSON column, **and/or**
- Select specific headers to map directly to columns (e.g., `X-Next-Page` → “Next Page Cursor” column).
- **Consistency with existing outputs:**
- Display “Response Headers” alongside “Response Body” and “Status Code” in the Call API action sidebar.
- Ensure headers are available in subsequent actions/conditions within the same workflow (e.g., use a specific header value in a conditional step).
- **Developer experience:**
- Provide documentation showing:
- How to reference a specific header (e.g., `response.headers["X-Next-Page"]` pattern in Glide’s UI).
- Examples for pagination, rate limiting, and token refresh flows using headers.