Add a line breaking mechanism to FormattingWriter

Until now, you could only call nextLine(), which would simply force a
new line to be written. This was ridiculously unsophisticated and led to
ugly corner cases (there should be a blank line between two methods, but
not necessarily between a method and the class’s opening or closing brace).

In the new model, any token can declare how many line breaks it wants to
allow before and after it. For example, a statement-ending ‘;’ allows
0..2 line breaks behind it (0 for comments, 2 for blank lines), a body’s
closing brace allows 0..1 line breaks before it (0 for single-command
blocks, 1 is the “normal” case). For the border between two tokens, the
intersection of these ranges is made, and then the amount of _existing
line breaks in the token stream_ is clamped into that range and used.

The fact that we reuse the existing line breaks and only “sanitize” them
is really cool, because it means that the following is (with appropriate
options) already well-formatted:

    void run() {
        print("Hello");

        // do something different
        value v = process.arguments.first;
        if (exists v) { print(v); }

        print("Bye");
    }

Note the blank lines that separate sections of the code, as well as the
one-line block. Both were not possible previously.

It also means that we use the user’s line wrapping if it’s already okay:

    fun(callChain(longArguments(north, something1), arg),
        callChain(longArguments(east, something2), arg),
        callChain(longArguments(south, something3), arg),
        callChain(longArguments(west, something4), arg));

(I wanted to write that Eclipse would move the callChain token up
because it still fits into the previous line, as I remember that having
been really annoying – but Eclipse no longer seems to do that. The
formatter must’ve gotten smarter sometime.)
This might make #11 obsolete.

What’s still missing is heaps of options for these line break ranges,
and documentation. I’ll add these in separate commits.

Closes #24.

Many of the test cases had to be updated because the unformatted code
was _too_ ugly, and some of the line breaks would be used in the
formatted output.