feat(WelcomeScreen): welcome screens

[almostSouji]

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

Implement Guild#fetchWelcomeScreen, Guild#editWelcomeScreen, add welcome screen data to invites retrieved via invite fetching (Client#fetchInvite) as per:

• Document welcome_screen on Guild object discord/discord-api-docs#1636
• Document Welcome Screen Endpoints discord/discord-api-docs#2398

Notes:

• (reverted) QoL change for BaseGuildEmojiManager to accept the <:name:id> and name:id syntax in resolve* methods
• ⚠️ Due to the nature of the emoji data we receive, this requires for Emoji#animated to potentially return null, making this a semver major PR. (upstream issue see below, not too much hope on that happening, though)
• ⚠ Changing the return value of Invite#guild (major)
• implement "enabled" via getter from guild features to not rely on upstream
• in-function reply is a hacky workaround for circular dependencies
• introduce intermediary, abstract guild to not dupe code for Guild and InviteGuild

Upstream:

• Welcome screen data should include "enabled" property discord/discord-api-docs#2795 can be handled via guild feature
• Welcome Channel Emoji data should include "emoji_animated" discord/discord-api-docs#2796

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• This PR changes the library's interface (methods or parameters added)
• This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[SpaceEEC]

Is it intentional to not populate / overwrite / update Guild#welcomeScreen when fetching or editing it? If yes, why?

[almostSouji]

Not too sure how to handle any of this for what it's worth

• we don't get a GUILD_UPDATE event for when this thing updates
• guilds will only ever have a welcomeScreen if they arrive via an invite (which also creates pseudo/partial/very empty guilds based on the little information we get from it, but doesn't cache them)
• what even happens if we have a guild cached and then fetch an invite from it?
• if we populate and update #wecomeScreen on fetch/edit that data immediately becomes out of date, since we don't receive any WS events to continuously update the screen based on

An entirely different approach could be to emit an InviteGuild which is directly attached to invites and reflects the guilds state at the point the invite was created/arrived, so we don't have outdated data in caches.

This problem also arises with interactions and the new #permissions field which reflects permissions after overwrites are applied in the channel the interaction was used in at the time the interaction was used.

[almostSouji]

how should i handle welcome screen data from invite guilds?
a) cache and update when the screen is fetched
b) cache and don't update
c) build invites with an InviteGuild, which has that property and extends Guild, cache without it as a regular guild (if from a server the bot is on)

[vladfrangu]

Only thing I have to say is #5490 (comment)

[vladfrangu]

how should i handle welcome screen data from invite guilds?
a) cache and update when the screen is fetched
b) cache and don't update
c) build invites with an InviteGuild, which has that property and extends Guild, cache without it as a regular guild (if from a server the bot is on)

Option c sounds ideal, but I don't know what others think. @iCrawl @kyranet?

[iCrawl]

Option C sounds reasonable (maybe a bit overkill, but what isn't in the current state of the library) and in line with the pattern we do it for other resources.

[kyranet]

There are merge conflicts in this PR, please rebase @almostSouji.

Also, since this seems blocked/pending review resolution, should this be marked as draft?

[SpaceEEC]

Maybe add a mention of InviteGuild in BaseGuild too (and mark it as @abstract) while are at it? 😅

[SpaceEEC]

I think BaseGuild also needs an abstract in the typings.

Stale

[almostSouji]

reverted accepting broader emoji data after internal discussion following proposal #5839