Better semantics around message REST methods

[FasterSpeeding]

Summary

Since webhooks are going to eventually be more commonly used as interactions are introduced it'd be helpful to improve the semantics around "responding" to (message.respond), "editing" (message.edit) and "deleting" (message.delete) messages as to take advantage of the webhook flow.

Problem

This change will likely be breaking and should be brought in to avoid encouraging behaviour which could lead to errors when the bot can't execute the wanted action on a webhook message and inconsistent behaviour like switching between webhook execution and message on response.

Ideal implementation

This may be implemented by differentiating between messages received through a webhook flow and messages received else with different classes being used for each. The main difference between the two would be the signature and implementation of message.respond, message.edit and message.delete, and the fact that the webhook message would enforce that webhook_id is always present while also tracking the webhook token.

There may also be abstract respond, edit and delete methods with more generic signatures (meaning they only have fields that are available for both webhooks and bot execution) on the message class they both inherit from but this might be messy to implement with how we currently handle partial messages.

Checklist

• I have searched the issue tracker and have made sure it's not a duplicate.
  If it is a follow up of another issue, I have specified it.

[FasterSpeeding]

This will likely rely on the ExecutableWebhook mixin present in #577 so marked as blocked for now