feat(Client): add apiResponse and apiRequest events

[ckohen]

Please describe the changes this PR makes and why it should be merged:

Adds an event emitted on every response received from the API, closes: #6707
This is quite useful for debugging purposes, especially when trying to figure out if something may be a Discord bug and not on the library side.

Some things to consider:

• Name of the event, I feel like this is accurate now, but naming things is hard
• In order to accomplish this, I've added docs / types to APIRequest, which makes changing it potentially breaking (e.g. if we wanted to fully replace rest with @discordjs/rest). To avoid this I could pull out specific properties from the request and only emit those, bonus to this being less chance of mutating (only matters when the request needs to be retried).
• In order to type the response, I had to add @types/node-fetch (since we don't target DOM), which does not have a version matching the version in the library since v3 has built in types. This could easily be solved by refactor: node-fetch & @discordjs/formdata -> undici #6586 or updating node-fetch

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating
• This PR changes the library's interface (methods or parameters added)

[SpaceEEC]

I think the event name is fine.

I'd be in favor of extracting relevant properties of APIRequest into an interface instead of documenting and emitting it.

This also does not seem to address the request for an apiRequest (when a request is being made) event, which was part of the linked issue. 👀

[vladfrangu]

Main issue I see is below. Also, I agree with @SpaceEEC, we shouldn't document the full internal class we have but just an "object" of it (honestly you might be able to just do { ...request } as well), because users shouldn't call make() themselves

[smol-skyz]

This also does not seem to address the request for an apiRequest (when a request is being made) event, which was part of the linked issue. 👀

The apiResponse event is what I was looking for, though it would be ideal to also have an apiRequest event too since some use cases might not require the response and I'm not sure what would happen if the request actually fails (if the event would get emitted or not).

[KhafraDev]

which does not have a version matching the version in the library since v3 has built in types. This could easily be solved by refactor: node-fetch & @discordjs/formdata -> undici #6586 or updating node-fetch

Discord.js cannot upgrade to node-fetch v3 due to it being ESM-only whilst this project is CJS.

[ckohen]

Discord.js cannot upgrade to node-fetch v3 due to it being ESM-only whilst this project is CJS.

I think we'd be able to async import it. Regardless, that's the harder of the options at this point

[ckohen]

At what point would you expect the apiRequest event to be fired? I'm going to put it right before the request for now, but there could be an argument for emitting before waiting out ratelimits.

[iCrawl]

This needs a rebase.

Stale

[iCrawl]

This needs a rebase.