perf: only generate data-comment-url once

[Gusted]

• Resolves Generate new-comment-url once instead of n times for PRs #17167
• Don't generate the same data-comment-url over and over for each
  edited LOC.
• Set data-comment-url for top-table of diff output.

Data for diff with 2.5K additons 0 edits 0 deletions:

No-patch:
Split: 2.82 MB
Unified: 2.37 MB

Patch:
Split: 2.59 MB (-8.2%)
Unified: 2.15 MB (-9.3%)

[silverwind]

I don't quite understand why this has such a big performance impact. I thought variables like .Issue.HTMLURL are generated once and then the result is (cheaply) substituted into the template. Why does it have such a big impact?

If there is significant computation involved when substituting vars in templates, we ought to apply this technique to a lot more variables.

[Gusted]

I don't quite understand why this has such a big performance impact. I thought variables like .Issue.HTMLURL are generated once and then the result is (cheaply) substituted into the template. Why does it have such a big impact?

If there is significant computation involved when substituting vars in templates, we ought to apply this technique to a lot more variables.

I think, I've missed the nail by naming this PR - it's a performance improvement in the sense that the size that's being sent to the client is smaller as the repeated attribute is not in each new LOC, but instead only sent once into a top-element.

[wxiaoguang]

LGTM. More thoughts:

1. Can data-path="{{$file.Name}} be moved to out like data-comment-url?
2. Can {{svg "octicon-plus"}} be improved, too?

[silverwind]

Can {{svg "octicon-plus"}} be improved, too?

It likely can not without <use> which we previously had but we dropped it because it doesn't work cross-origin, so I think the current SVG rendering solution is optimal.