FormattingWriter: don’t add LineBreaks directly

fastForwardComments would previously add LineBreaks directly to the
tokenQueue instead of including them in the returned sequence of
to-be-added tokens.
FormattingWriter: make param givenLineBreaks of fastForwardComment optional

We can only fast-forward a comment if there are tokens, in which case
we’re guaranteed to have givenLineBreaks as well.
FormattingWriter: remove param givenLineBreaks of fastForwardComment

well that was stupid
Fix line breaks after line comments for #29
FormattingWriter.fastForwardComment: very minor

move trimTrailing('\r') to lines instead of applying it to firstLine and
lines.rest separately
FormattingWriter.fastForwardComment: small refactor

Move the OpeningToken constructor calls all to one place.
FormattingWriter.fastForwardComment: fix multi-line

fastForwardComments predates string literals, so I used to split the
comment token by its line breaks and write each line as a separate
token. This would turn

        /* an indented
           multi-line comment */

into

        /* an indented
              multi-line comment */

because subsequent lines would get regular indentation + the indentation
that was still contained in the token text.

I solved this problem a while ago for string tokens; I just have to use
that solution for multi-line comments as well.

Side note: ANTLR sometimes has an incorrect charPositionInLine for the
first token; in the case of helloWorldCommented, this had the effect
that 17 characters of whitespace were stripped from each line of the
initial comment. That’s what the special case is for; I’ll have to
investigate if there’s a better way to fix this.

Also, this comment completely enables dogfooding (#29) – the formatter
was already able to format itself since c78f371, but now running the
formatter a second time introduces no new changes.