APIChannel types could be more "strict"

[cyyynthia]

Issue description

A lot of the fields of APIChannel-related types are marked as optional, where in practice they are not for the given channel type.

Here's an example: for APIThreadChannel, the thread_metadata property is marked optional (which is according to Discord's documentation of the channel data object is correct) - however, I haven't seen any instance where for a thread channel this data was missing. For Group DMs, the owner_id field should always be present (including when the GDM is from an app), but is marked as optional.

This makes it harder to know to know which fields are consistently there, as the types tend to be overly conservative over marking these fields as optional. This also means additional unnecessary guards (or worse, some !) have to be added due to TypeScript rightfully emitting errors.

name is an example of property that has been strongly typed per-type, rather than using Discord's generic description of "optional, possibly null string". I feel like this should also be done for other properties.

Code sample

function isThreadLocked (thread: APIThreadChannel): boolean {
  // Error! thread_metadata might be undefined.
  return thread.thread_metadata.locked
}

async function getGdmOwnerUser (gdm: APIGroupDMChannel): Promise<APIUser> {
  // Error! owner_id might be undefined.
  return fetch(`.../users/${gdm.owner_id}`, { ... }).then((r) => r.json() as Promise<APIUser>)
}

Package version

0.37.22

Runtime

Node.js

Runtime version

v18.12.1

Priority this issue should have

Low (slightly annoying)

[vladfrangu]

Be our guest to tackle this beast if you desire!