[Feature/Discussion] Expose more low-level APIs, remove "internal" access modifier from DiscordRestApiClient

[eesquibel]

Expose more low-level APIs, remove "internal" access modifier from DiscordRestApiClient, among others.

I may be missing the background to this, but there seems to be a preference toward internalizing a very large set of the backend APIs used by the Discord.NET project.

This really limits the use for the library in more creative use-cases.

My personable example:

• My project is split into a series of workers each running in a container (Docker).
• The primary work interacts with Discord directly and in the SlashCommandExecuted event, it adds the user-requested command to an external queue (RabbitMQ) and tells the Discord API the processing of the command is deferred (via SocketCommandBase.DeferAsync).
• A second worker consumes the queue messages and processes the slash command The underlying design goal is for the worker container that interacts with Discord to be unconcerns by the exact implentation of each slash command, ergo each command being the responsibility of a separate worker.

Unfortunately, there is no direct way via the Discord.NET public APIs to update the interaction response outside of the initial SlashCommandExecuted event handle as all the associated classes either have internal constructors, or the underlaying service classes that execute the webhooks/{application}/{token}/messages/@original requests are themselves marked at internal.

I would love to see more of these low-level APIs exposed so more creative use-cases for the library can be used and not limited by such an opinioned design framework.

[csmir]

Discord.Net holds the hands of the developer in getting and using entities by design. While the idea is wonderful, it very much does the opposite of what Discord.Net actually intends to be. I will move this to a discussion and request a followup of other contributors.