This is to be more consistent as there is already a :read_note policy in
NotePolicy. To keep other behaviour the same we've introduced a
Note#noteable_ability_name that is used anywhere this was expected.

A new `discussion_id` argument on the `createNote` mutation allows
people to create a note within that discussion.

The ability to lazy-load Discussions has been added, so
GraphQL.object_from_id can treat Discussions the same as AR objects and
batch load them.

https://gitlab.com/gitlab-org/gitlab-ce/issues/62826
https://gitlab.com/gitlab-org/gitlab-ee/issues/9489

This exposes `Note`s on Issues & MergeRequests using a
`Types::Notes::NoteableType` in GraphQL.

Exposing notes on a new type can be done by implementing the
`NoteableType` interface on the type. The presented object should
be a `Noteable`.

Sets `updated_at` so that the transformed note is returned together with
the new reply

Partially addresses #47424.

When a merge request can only be merged when all discussions are
resolved. This feature allows to easily delegate those discussions to a
new issue, while marking them as resolved in the merge request.

The user is presented with a new issue, prepared with mentions of all
unresolved discussions, including the first unresolved note of the
discussion, time and link to the note.

When the issue is created, the discussions in the merge request will get
a system note directing the user to the newly created issue.

* Added keyword arguments to truncated_diff_lines method to allow for using highlighting or not (html templates vs. text)
* Tweaked templates for consistency and format appropriateness

Previously the `truncated_diff_lines` method for outputting a discussion diff took in already highlighted lines, which meant it wasn't reuseable for truncating ANY lines. In the way it was used, it also meant that for any email truncation, the whole diff was being highlighted before being truncated, meaning wasted time highlighting lines that wouldn't even be used (granted, they were being memoized, so perhaps this wasn't that great of an issue). I refactored truncation away from highlighting, in order to truncate formatted diffs for text templates in email, using `>`s to designate each line, but otherwise retaining the parsing already done to create `diff_lines`.

Additionally, while notes on merge requests or commits had already been tested, there was no existing test for notes on a diff on an MR or commit. Added mailer tests for such, and a unit test for truncating diff lines.

Use `update_all` to only require one query per discussion to
update the notes resolved status. Some changes had to be made to
the discussion spec to accout for the fact that notes are not
individually updated now

Speedup DiffNote#active? on discussions, preloading noteables and avoid touching git repository to return diff_refs when possible

- Preloading noteable we share the same noteable instance when more than one 
discussion refers to the same noteable.
- Any other call to that object that is cached in that object will be for any 
discussion.
- In those cases where merge_request_diff has all the sha stored to build a diff_refs get that 
diff_refs using directly those sha instead accessing to the git repository to first get the 
commits and later the sha.