add deleted timestamp for deleted msg events

[zFlabmonsta]

When a slack message is deleted an event is sent with the deleted_timestamp field in the payload.

{
  "token": "*****",
  "team_id": "*****",
  "enterprise_id": "*****",
  "context_team_id": null,
  "context_enterprise_id": "*****",
  "api_app_id": "*****",
  "event": {
    "type": "message",
    "subtype": "message_deleted",
    "previous_message": {
      "client_msg_id": "*****",
      "type": "message",
      "text": "kkkk",
      "user": "*****",
      "ts": "1707375397.979789",
      "blocks": [
        {
          "type": "rich_text",
          "block_id": "Ygihn",
          "elements": [
            {
              "type": "rich_text_section",
              "elements": [
                {
                  "type": "text",
                  "text": "kkkk"
                }
              ]
            }
          ]
        }
      ],
      "team": "*****",
      "user_team": "*****",
      "source_team": "*****",
      "thread_ts": "1707372155.446849",
      "parent_user_id": "*****"
    },
    "channel": "*****",
    "hidden": true,
    "deleted_ts": "1707375397.979789",    // <----
    "event_ts": "1707392586.005800",
    "ts": "1707392586.005800",
    "channel_type": "channel"
  },
  "type": "event_callback",
  "event_id": "*****",
  "event_time": 1707392586,
  "authorizations": [
    {
      "enterprise_id": "*****",
      "team_id": null,
      "user_id": "*****",
      "is_bot": true,
      "is_enterprise_install": true
    }
  ],
  "is_ext_shared_channel": true,
  "event_context": "*****"
}

Pull Request Guidelines

These are recommendations for pull requests. They are strictly guidelines to help manage expectations.

PR preparation

Run make pr-prep from the root of the repository to run formatting, linting and tests.

Should this be an issue instead

• [ ] is it a convenience method? (no new functionality, streamlines some use case)
• [ ] exposes a previously private type, const, method, etc.
• [ ] is it application specific (caching, retry logic, rate limiting, etc)
• [ ] is it performance related.

API changes

Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.

• no tests, if you're adding to the API include at least a single test of the happy case.
• If you can accomplish your goal without changing the API, then do so.
• dependency changes. updates are okay. adding/removing need justification.

Examples of API changes that do not meet guidelines:

• in library cache for users. caches are use case specific.
• Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.

[zFlabmonsta]

@parsley42 👋 , pretty simple addition