Include the changes in issuable webhook payloads

What does this MR do?

This adds a changes key to the issuable webhook payloads, e.g.:

  "changes": {
    "updated_by_id": {
      "previous": null,
      "current": 1
    },
    "updated_at": {
      "previous": "2017-09-15 16:50:55 UTC",
      "current": "2017-09-15 16:52:00 UTC"
    },
    "labels": {
      "previous": [{
        "id": 206,
        "title": "API",
        "color": "#ffffff",
        "project_id": 14,
        "created_at": "2013-12-03T17:15:43Z",
        "updated_at": "2013-12-03T17:15:43Z",
        "template": false,
        "description": "API related issues",
        "type": "ProjectLabel",
        "group_id": 41
      }],
      "current": [{
        "id": 205,
        "title": "Platform",
        "color": "#123123",
        "project_id": 14,
        "created_at": "2013-12-03T17:15:43Z",
        "updated_at": "2013-12-03T17:15:43Z",
        "template": false,
        "description": "Platform related issues",
        "type": "ProjectLabel",
        "group_id": 41
      }]
    }
  }

Are there points in the code the reviewer needs to double check?

1. I've decided to always include the assignees key since issues and merge requests respond to it, and because MR will soon support multiple assignees, so it doesn't hurt to start returning assignees for MR too. The assignee key is still present for MR, but deprecated.
2. In the new changes hash, I only included assignees (no assignee) since there is no back-compat to keep here).

Why was this MR needed?

Because some projects need this, see #34284 (moved).

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• Tests added for this feature/bug
• Review
  • Has been reviewed by Backend
  • Has been reviewed by Database
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together

What are the relevant issue numbers?

Closes #34284 (moved)