feat(REST): allow options.query as URLSearchParams

[Fyko]

Please describe the changes this PR makes and why it should be merged:
This PR adds support for a request's query option to be either an object or URLSearchParams.

This is necessary for #4142 to function. thanks vlad
Status

• 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

Semantic versioning classification:

• This PR changes the library's interface (methods or parameters added)
  • This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
• This PR only includes non-code changes, like changes to documentation, README, etc.

[izexi]

Instead of expanding an instance of an URLSearchParams into an array and then constructing URLSearchParams again, Object.entries(options.query) could be reduced into an array of [key, value] where each value is mapped out into [key, eachArrayValue] (when it's an array). Something like this for example:

const query = Object.entries(options.query)
  .filter(...)
  .flatMap(([key, value]) =>
    Array.isArray(value) ? value.map(v => [key, v]) : [[key, value]]
  );

Then we can always pass an object as options.query, for example: { foo: 'bar' } / { foo: ['bar, 'baz'] } which would result into [ ['foo', 'bar'] ] / [ ['foo', 'bar'], ['foo', 'baz'] ]. This seems somewhat more consistent, and I think it makes more sense to handle the query within here rather than having to construct an URLSearchParams over on the API method.

[Fyko]

@izexi, sounds good! consider it done :)