Added extra newlines in pretty tokenstream

[RunDevelopment]

This changes the pretty simplified token stream to have an extra newline if the test code also has a double newline there.

Example

+ - * / %
> >= <= < == != =
!~ =~

! && ||

[**] [***] [****]

..
1..100

-------------------------------------------------------------

[
    ["operator", "+"],
    ["operator", "-"],
    ["operator", "*"],
    ["operator", "/"],
    ["operator", "%"],
    ["operator", ">"],
    ["operator", ">="],
    ["operator", "<="],
    ["operator", "<"],
    ["operator", "=="],
    ["operator", "!="],
    ["operator", "="],
    ["operator", "!~"],
    ["operator", "=~"],

    ["operator", "!"],
    ["operator", "&&"],
    ["operator", "||"],

    ["punctuation", "["],
    ["operator", "**"],
    ["punctuation", "]"],
    ["punctuation", "["],
    ["operator", "***"],
    ["punctuation", "]"],
    ["punctuation", "["],
    ["operator", "****"],
    ["punctuation", "]"],

    ["range", ".."],
    ["number", "1"],
    ["range", ".."],
    ["number", "100"]
]

------------------------------------------------------

This is the output pretty token stream as is.
The different operator groups are neatly separated by an extra newline.

This makes it easier to read long token streams without having to do any manual formatting.
I wanted this feature because this is how I usually format pretty token streams.

[RunDevelopment]

I can't merge this without a definition of a token stream. (These tests don't fail for nothing.)

Sorry, if I haven't made this clear that #2071 blocks this PR.

[mAAdhaTTah]

Oh, I see, my bad. So as I commented on #2071, I would be in favor of bringing the types into alignment with the actual runtime behavior. Whatever properties of TokenStream tokenize actually produces at runtime should be reflected in the TokenStream type. If our current types are suggesting it returns things it doesn't, then I'd go with the simpler types, especially if your code has made assumptions about what tokenize produces and functional correctly with those assumptions.

[RunDevelopment]

Ok yeah. I just looked at Markup templating and it also assumes the narrower definition. The minor difference here: While this code might break for other definition, MT is going to break, no questions. (See walkTokens in MT).

I'm gonna change the definition in #1782.