feat: rate limiting information for all responses

[gabrielmfern]

Closes #189.

Adds a type to use on all responses to avoid repeating the definition for it, and add a rateLimiting field there that gives access to the ratelimit-limit, ratelimit-reset and ratelimit-remaining headers.

The actual changes to use the new Response type were made by claudinho, so take that portion with a grain of salt

Here's how an example of the API would feel like:

const response = await resend.emails.send(/* ... */);

//  limit: number;
//  remainingRequests: number;
//  shouldResetAfter: number;
if (response.rateLimiting?.remainingRequests === 0) {
	setTimeout(() => {
		// ...continue making requests...
	}, response.rateLimiting.shouldResetAfter * 1000);
}

Unfortunately, there are a few cases that are errors that happen on the client and not on the server, so if error is not null, rateLimiting can be null. Ideally the user would not need to handle that, but seems like it's unavoidable.

Additionally, this also adds in a retryAfter property to the ErrorResponse when the name is 'rate_limit_exceeded' taken from the retry-after header that only comes on 429 responses. It feels like this:

const response = resend.emails.send(/* ... */);

if (response.error?.name === 'rate_limit_exceeded') {
	setTimeout(() => {
		/* ...code for retrying... */
	}, 1000 * response.error.retryAfter);
}

[joaopcm]

What if we gracefully fail here? This would be a big problem if we change how the rate limit works in the API

[gabrielmfern]

that function is only called from

resend-node/src/resend.ts

Lines 60 to 62 in 983cc6a

	const rateLimiting = parseRateLimit(response.headers);

and there it errors gracefully, but with an error message that isn't very clear. we could return something else for when it isn't able to get the rate limiting headers, I also thought of just warning, but my worry with not erroring here is that it could break workflows for users silently

imo the best would be to have tests on the SDK's side that tested things directly with the production API ensuring that this rate limiting is working so it would fail early, instead of doing mocking