Allow inline summary cutoff

[clarfonthey]

• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Are you doing the PR on the next branch?
• Have you created/updated the relevant documentation page(s)?

This worked previously, but was broken by a recent change. Essentially, because the InlineHtml event is not considered for the <!-- more --> marker, it has no meaning at the moment when not placed on its own line.

This alters the code to allow this again, but does so in a more reasonable way:

1. It properly closes tags that are left open in the summary. (Inline HTML is not considered; you're on your own if you do that.)
2. It runs a summary-cutoff.html template at the end of the summary if this happens, which acts depending on the summary before the cutoff and the current language. It defaults to showing an ellipsis if the summary doesn't end in punctuation.

I've also added tests to verify this behaviour works.

Fixes #2562.

[Keats]

Honestly I'm not too sure about that. The original intent when it was added was to put it on an empty line and putting it in the middle of some HTML - I don't know...

[clarfonthey]

That's extremely fair. In my case, I don't use it very often, but the current case where I do use it is for cutting sentences off as a kind of cliffhanger. Things like "So, I took a look at X, and <cutoff>". I just made a complete version that accounts for all kinds of markdown syntax because if I was going to do anything, I might as well do it right instead of just adding a </p> sometimes. (Which is what my code did before this was properly supported.)

And like, I guess that there might be cases where you might want to cut off in the middle of a blockquote or something, although those are probably much rarer.

If you do want it to remain on its own line, I can remove the summary-specific stuff and just keep it to fixing shortcodes for now. I do think that <span>{{ code() }}</span> not working and {{ code() }} working by itself is a little weird.

[nyanpasu64]

Not sure about the technical details of this PR (I haven't looked into the code), but I found that even <!-- more --> in the middle or end of a regular Markdown paragraph (without HTML elements) is no longer detected as a marker. I use this heavily in my blog (https://nyanpasu64.gitlab.io/), including breaking summaries in the middle of a paragraph, and cannot update to 0.19.x until this is fixed. Is this related to this PR?

[clarfonthey]

Short answer, yes,

Long answer, yes but it will change the code so that it actually emits the end of the paragraph and leave a cutoff marker in its place, so, you will need to modify your templates if they were manually adding the paragraph end marker back (alongside an ellipsis) in some capacity.

[LunarEclipse363]

2. It leaves a <span class="summary-cutoff"></span> element before those tags are closed so it can be properly styled. This is slightly more portable than just using an ellipsis, since you can choose what character to use via CSS instead.

This could potentially be a built-in template the user can override like anchor-link.html.

The issue with putting the ellipsis in via CSS is that some user agents (Atom/RSS feed readers for example) might not load the stylesheet at all and then the ellipsis is gone entirely. I'm also not sure what implications would it have for accessibility.

[clarfonthey]

This could potentially be a built-in template the user can override like anchor-link.html.

Actually, yeah, that seems the most reasonable. Could also provide the template with the contents of the summary so you could, for example, only emit an ellipsis if there isn't punctuation at the end of the line. I'll make that the default.

[clarfonthey]

Marking this as draft since I'm moving the shortcode fixes to a separate PR. Will rebase on top of that once it merges.

[clarfonthey]

Rebased this on the other change and added a template version of the summary cutoff. By default, it ends the summary in an ellipsis if it was cut off inline.