[API] Message edit history

Basics

When edit histories are enabled, previous revisions of the message should be accessible to anyone who has permission to read the message history. It should be possible to delete individual revisions of the message.

Detailed descriptions of the changes

When enabled in the server-side, message gets a new field revisions, a map of logical keys (content, embeds, attachments, components) to snowflakes, which point to their respective revisions. For backwards compatibility, content and related fields should return the current revision on non-E2EE messages, but in E2EE messages, or in case the client declares MESSAGE_INDIRECT feature, those fields should instead return pointers to the latest revisions of those. Each revision should keep its author and content, in addition to its ID. Each edit should update the message revisions array accordingly. Removed revisions should have content thereof deleted, just like removed messages. A message delete should remove all the revisions also. If one attempts to delete the only remaining revision of the entire content of a message, it should be treated as deleting the entire message.

The issue names no files, tests, or entry points. Start by locating the server-side message model and message edit/delete API paths, then trace how message fields and permissions are handled. Done means revisions are exposed and permissioned, edits and deletions update or remove them correctly, and the stated backwards-compatibility behavior is covered.