Restructure issue list template, styles

[denyskon]

This PR does various modifications on the issue list shared template:

• restructure layout to achieve better responsiveness
• fix various style issues
• restructure styles (better result with less code :)
• remove numerous gt-* patches and other unneeded classes -> use existing css classes

Before:

After:

[silverwind]

One idea I had in mind is to move from .issue.list to a better name and a single class name. The styles originate from the issue list but a number of other lists now use it as well, so the name is not accurate any more. We'd need a somewhat generic name, maybe call it flex-list or similar. Doesn't have to be in this PR of course.

[denyskon]

@silverwind I plan to merge all the similar & often partially broken 'card styles/templates' into one at some point as most of them use a similar layout: leading icon/image, title, subtitle/body, trailing icons/buttons. I thought it would be better to start with this small refactoring.

I would prefer if we could merge this now, and an/some additional PR(s) will follow soon continuing with this approach.

[silverwind]

Yes, of course. Step by step.

[denyskon]

I have started refactoring the other card elements to use this card structure, and it looks like it's easier to do it in one PR so nothing breaks in between...

[wxiaoguang]

It looks clearer than before, and it fixes more SVG alignments.

[GiteaBot]

@denyskon please fix the merge conflicts. 🍵

[wxiaoguang]

The conflicts are caused by Reformat some templates #25756

That's what I said in #25739 (comment)

No reformat. To avoid unnecessary diff and unnecessary merge conflicts
...
It's not a weak reason now since there are a lot of frontend refactoring.
Otherwise some PRs would lose changes when resolving conflicts, for example, I fixed merge errors in #25625.....
If there is no "indent" change, git can merge most of the changes flawlessly.

[silverwind]

Maybe if we could get the backend to just "minify" the insignificant HTML whitespace, it would be ideal, but I'm not sure whether the extra the processing cost of such an effort is worth it.

[wxiaoguang]

To help merge this PR, you can do this:

1. Re-format the conflicted templates on your side following Reformat some templates #25756
2. Then do a git merge, then git should be able to auto merge most changes without losing code

[silverwind]

Could probably do template optimization as a one-time action on process startup and then cache the result in memory.

[wxiaoguang]

I do not think it's worth to play with these spaces at the moment, neither the spaces between tags nor the spaces between class names.

Just like you won't look into the generated assemble code in a binary program, won't look into the generated JS code after packing, nobody would be hurt by the generated HTML code for browsers -- as long as the browser can render it correctly.

Code should be written in a developer-friendly style, but not in a generated-content-friendly style.

[silverwind]

Agree it's not worth from a review standpoint, but delivering minimal HTML is worth from performance standpoint.

[denyskon]

Fixed the conflicts