Warn/error if jldoctest starts with an empty line; or lacks empty line between two REPL prompts

[fingolfin]

These are minor usability errors, "paper cuts" if you will, that have annoyed me repeatedly in the past, and clearly also other people:

Resolves #2031
Resolves #2083
Resolves #2679
Alternative to and hence closes #2810

Alternative in PR #2810: we could also just allow all of this. (For the leading empty line: Should it then be rendered, or hidden?)

Downside: such a doctest would not work with older Documenter versions. I therefore am inclined to prefer the strict version implemented here.

But in the end, either is preferable over the current errors.

(I am waiting with changelog and test cases until I know which direction we'll take)

[fingolfin]

Advantages of a loose version:

• repl_splitter can stay being a function with one argument, which might be interesting for external projects
• "it just works" experience for users (instead of forcing the user to adapt to the code, let the code adapt to the user)
  • note that doctests failing the tests being added here can be copy&pasted into a Julia REPL just fine, they work there, so why not in Documenter
• ...

[mortenpi]

I am inclined to turn these into errors/warnings (i.e. doctest failures):

• Empty line at the top just looks weird. Not sure why anyone would want that. So let's "lint" it away.
• Between the prompts, the Julia REPL always forces an empty line between prompts. So I think it's reasonable to require this. It also feels like it should help with the heuristic a bit..

Requiring empty lines would mean that this case should be fine:

But it also shouldn't error. Also I feel like it should parse fine right now (but maybe it doesn't?).

So maybe the correct thing to do here is to parse. And when a doctest fails, then check if there is a ^julia> match somewhere in the output part (i.e. a missing empty line), and add to the error/warning we print to the user that "hey, maybe this is meant to be two separate prompts"? This would resolve #2083 I think?

[fingolfin]

Thinking some more about this, my conclusion is that the argument "this code can be pasted fine into the REPL, so we should accept it" isn't so great after all. I think the converse which @mortenpi brought up at least implicitly carries more weight: what does the output of the REPL look like? I think having the rule "the doctest content should match the REPL output exactly is more important.

Besides, if we reject it now, we can always switch to accepting it in the future. The other direction is much harder.

So I'd say, let's indeed go with this PR over the other.

I'll add some tests and a changelog entry.

[fingolfin]

Add changelog entry, added a test -- I split this into two commits: the first commit adds the test with the current output. The second commit has the fix and adapts the test to the new output. This way one nicely sees the difference in quality between old and new message.