XResultHandler should expose MessageProperties creation

[csmir]

This PR exposes the GetFailMessageAsync function in:

• ApplicationCommandResultHandler<T>
• ComponentInteractionResultHandler<T>
• CommandResultHandler<T>

In order to allow implementations to change or replace the behavior of failure message creation.

Breaking: The MessageFlags? messageFlags = null parameter in all three result handler implementations has been removed in favor of implementation-first design for pushing the MessageProperties.Flags variable user-side.

An alternative to this approach is considering to expose delegate defaults for these classes, e.g.

public sealed class DelegateApplicationCommandResultHandler(Func<..., ValueTask> resultDelegate) { ... }

configuration.ResultHandler = new DelegateApplicationCommandResultHandler((...) => { ... });

[github-actions]

The documentation preview is available at https://preview.netcord.dev/378.

[KubaZ2]

Maybe it would be a good idea to change GetFailMessage to ValueTask<...> GetFailMessageAsync?

[csmir]

Do we care about asynchronicity in such a function? Or are we thinking about potential user-side scenarios that might?

[KubaZ2]

I can think someone may want to call a database to format a message or something like that.

[csmir]

That seems fair, I'll change this then.

[KubaZ2]

Suggested change

	var messageProperties = await GetFailMessageAsync(failResult, context, services).ConfigureAwait(false);
	return new(interaction.SendResponseAsync(InteractionCallback.Message(message)));
	await interaction.SendResponseAsync(InteractionCallback.Message(messageProperties)).ConfigureAwait(false);
	var message = await GetFailMessageAsync(failResult, context, services).ConfigureAwait(false);
	await interaction.SendResponseAsync(InteractionCallback.Message(message)).ConfigureAwait(false);

and same for the other result handlers

[csmir]

This does not compile because message is already reserved on all handlers for upper logic.

[csmir]

* Apologies, on the CommandResultHandler specifically. On others it works. For consistency I believe differentiating is inelegant.

[csmir]

Please consider my patience for further nitpicky code suggestions. In open source it is most expected that functional and convention-matched code should be ready to merge. If you disagree, write a CONTRIBUTORS document that prepares developers on how to work on NetCord.

I do not mean to insult or look any the wiser. I just do not know what you expect. This back-and-forth on only appearance and no functional changes is time costly.

Please make one final look-through to make this merge-ready with me.

I will not handle any further iterations past the next, you can pick up the pull request yourself if you have anything more to add after this.