Support multiple assignees for merge requests

What does this MR do?

It has the feature code changes required in order to support multiple assignees for merge requests, it includes:

• Notifications
• General multi-user layout selects (reused from Issues)
• It creates the relation based on the deprecated assignee_id if the feature flag is OFF. That means we use the new relation regardless of the feature flag being ON or OFF. There'll be another MR to automatically enable the feature flag when the background migrations finishes running (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26496)
• It removes the belongs_to :assignee but still don't remove the assignee_id column. This should come in a next release.

To be handled in a separate MR

• Background job to automatically enable the feature flag once the background migration is done. We need to have a way to enable it for self-hosted instances
• Docs update

TODO

• Create migration
• Create population post-deploy migrations
• Make use of existing Vue components on MR sidebar assignees
• Assignee assign / unassign is not working properly (UI)
• Add 'cannot merge' tooltip
• Present multiple-assignees for MR lists
• Present multiple-assignees for approval emails
• Try to fix QA reusing logic from app/views/shared/issuable/form/_merge_request_assignee.html.haml
• Assignee assign / unassign notes are not being created
• Assignee assign / unassign quick action is not working properly

Screenshots

Emails

MR list and sidebar

What are the relevant issue numbers?

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/2004

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated via this MR
• Documentation reviewed by technical writer or follow-up review issue created
• Tests added for this feature/bug
• Tested in all supported browsers
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process.
• EE specific content should be in the top level /ee folder
• For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?
• Security reports checked/validated by reviewer