[WIP] Rework context types (#153, solution 3)

[Nihlus]

This PR is a companion to #233, presenting the discussed third solution in the original issue. Since the issue was written, a number of architectural changes to interactivity have happened which render quite a few of the considerations moot. The end result is a far simpler and more workable implementation of streamlined contexts with richer data available to the end user.

In summary, the PR does two things:

One - it reworks the contexts into a set of interfaces and concrete types with the ability to distinguish between operations that are both commands and non-commands, providing detailed typesafe information about both cases.

Two - it reworks the execution flow of the message and interaction responders in order to simplify and streamline the procedure. Primarily, this means that pre- and post-execution events now run closer to the actual execution of the command itself and have full access to both the command node and its materialized parameters.

However, this does mean that pre- and post-execution events no longer run for events that fail to parse into executable commands, such as NotFound or ParsingError faults. This is a change from the previous behaviour, in which post-execution events would still run for these failure modes, and is one of the reasons this PR is marked as WIP.

I'd like to get some community feedback before I merge this, as it may mean previously supported code no longer works as expected. Please leaf through the diagrams and the code :)

[carlst99]

Overall I think this is a great improvement! The only issue I have with this is not being able to detect command preparation errors. Nowadays with slash commands, it's less likely to be an issue. However, when using text commands I like to be able to inform the user when they've used a command incorrectly, or that it doesn't exist.
Personally, I don't mind if this isn't integrated with pre/post execution handlers. It looks to me like that might be troublesome. Simply being able to register a dedicated, context-aware handler for preparation errors would be enough.

[Nihlus]

That's definitely one solution I've considered. I'll let some more people chime in on their preferred solution before I do anything, though.

[VelvetToroyashi]

This PR is chonky due to the very broad scope of it, but I've done a skim over it, and see no real issues, except the aforementioned pre/post-execution one, but I believe I have a solution for that.

However, given the fundamental changes to how commands will be handled, I can only hope that an announcement will be made about this given how this is somewhat more than just "another breaking change".

[VelvetToroyashi]

Isn't this technically against the naming conventions for consts?

[VelvetToroyashi]

One solution that may be more or less apt is instead of adding another handler and type to maintain, the ICommandContext parameter could be changed to be Optional<ICommandContext> (or one could be created from the available information, and the error would indicate that things like PreparredCommand would be unavailable), and the pre-execution check would be run regardless, though this obviously requires both noting this behavior somewhere in the code, and informing users of the behavior, which can and probably will increase complexity in user code, since error handling would be split between pre/post execution events, but for different reasons.

I suppose it's a tradeoff between complexity for us and complexity for "them" (the end-users).
If this idea seems utterly asinine, I apologize in advance; running on 4 hours of sleep isn't exactly beneficial to the mind.

[Nihlus]

Having had time to fiddle with this some more, what do we think of this flow?

[Nihlus]

Actually, here's a better one.

[Nihlus]

It is, of course, still up in the air if we want to have the default tree fallback functionality at all - I can do without it, personally.

[VelvetToroyashi]

I can't say how often I've personally used it; it seems like a bit of a niche on top of a niche, however changing TreeNameResolver's API would be yet another breaking change.

[Nihlus]

To be fair, I did specify that it is up to the implementation if it wants to adhere to the AllowDefaultTree flag :P