Add common base type for interaction context types

[gdude2002]

Title. EphemeralInteractionContext and PublicInteractionContext have common behaviour that could be abstracted, and this would make writing generic command code easier.

[gdude2002]

I've been looking into this, and I have to surmise that a meaningful abstraction is difficult. This is largely due to discrepancies in the Discord API - specifically, Discord is not consistent regarding what your bot is capable of safely doing when dealing with interactions. For example:

• Public-acked interactions technically "support" ephemeral follow-ups, but they will be shown publicly in most scenarios
• Ephemeral-acked interactions with follow-ups sent twice, or at all after editing the initial response, can result in the follow-ups being shown publicly instead in some situations
• Both types of acked interactions may have the initial response edited, but ephemeral follow-ups may not be edited (and thus are unsuitable for paginators)

KordEx tries to reduce some of this entropy where possible, which is why there are abstractions everywhere. However, if I'm going to make a meaningful abstraction over both sets of behaviours, I'd either have to restrict the functionality available to both types of interaction significantly, or I'd have to keep some of the behaviours within each interaction-type-specific type, which means you've still gotta do a fair bit of casting for some work.

I could use some feedback on what approach to use here, or whether creating this abstraction is valuable given these restrictions.

[mazziechai]

I think casting shenanigans is probably the best bet if this was to be a thing. As the user who wanted this feature, it's ultimately not a big deal; the functionality that I used was able to be extracted to multiple different functions. While it does create code duplication that I have to deal with, this issue is specific to my use case (to my knowledge at least) and doesn't need an accommodation from KordEx (although it would still be useful and appreciated).

[Tmpod]

I've faced issues with this as well, when trying to make visibility-agnostic UI component sets, and have gotten around it with some code duplication, like @mazziechai. I had wondered why it wasn't implemented already, but never knew of those Discord inconsistencies...
Unfortunately, I'm not really seeing a good way to achieve this, I'd have to think a bit more about it.

Anyways, posting to give my small 2￠ and to maybe spark some more discussion :)

[gdude2002]

I've thought about this some more, and decided that probably the best thing to do here is to provide warnings via opt-in annotations for function calls that may result in unexpected behaviour. I think that's going to be my approach - I'll update this issue if I run into anything else.

[gdude2002]

I've just pushed this, and you'll find it released as part of 1.6.0-SNAPSHOT in 15 minutes or so.

Please note that the interaction response commands (e.g. respond, editingPaginator, etc) are now part of the base interface, and the imports will fail. You'll need to remove those imports.