Refactor: Make message components agnostic components

[suneettipirneni]

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

This deprecates all other Message* types, so this shouldn't be breaking.

It's breaking

This makes all components regardless of being a message component, or a modal component all inherit from the same base, and have no difference in variance between message and modal implementations. This is key refactor needed for the modal PR (#7023), and prevents future class proliferation of other component type variants.

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)

[suneettipirneni]

Just realized that this is going to need to be semver: major, because it changes the type of Message#components.

[ImRodry]

I don’t think there’s a use case where that would break though is there?

[suneettipirneni]

I don’t think there’s a use case where that would break though is there?

The only place I can think of is using instanceof checks. Although doing these types of checks is pointless anyways. But I'll defer this to @discordjs/the-big-4

[ImRodry]

Yeah there’s always that but I don’t think anyone would be doing this here. You can also make the old classes extend the new ones and I think the instanceof checks wouldn’t break here, right? This would work since I believe all properties and methods are the same right

[suneettipirneni]

If I made the new classes extend the old ones it would defeat the purpose of this PR.

[ImRodry]

My suggestion is to make the old ones extend the new ones. The properties are the same, but documented differently (at least how I see it) so it wouldn’t defeat the purpose would it?

[suneettipirneni]

My suggestion is to make the old ones extend the new ones. The properties are the same, but documented differently (at least how I see it) so it wouldn’t defeat the purpose would it?

Perhaps, but then you might run into the issue where instanceof BaseMessageComponent won't work. 🤔

[ImRodry]

I don't think anyone in their right mind would do such a thing but yeah you're right :/
Can we ignore that small nit?

[vladfrangu]

Small nit otherwise LGTM to me

[kyranet]

Please rebase, there are merge conflicts.

[iCrawl]

This needs a rebease.

[suneettipirneni]

So I'm probably going to close this PR and open another one later that uses the message components from builders instead.

[suneettipirneni]

Superceded by #7195