Fix bug where solver looks at the last piece on line instead of first. (#1367)

The Solver selects states for all pieces in the piece tree to decide
how to format. It does so by exploring a tree of incremental solutions
where each set of states is a node in the tree and branches are formed
by incrementally binding new states.

Exploring the full tree is massively slow. A key optimization is that
the solver only looks at changing the state of pieces on lines that
actually overflow or are invalid. That way pieces on lines that fit
and don't need to split are ignored.

It goes further: it only looks at the *first* piece on the *first* line
that overflows. Any pieces following that one may be affected by how
changing the state of the preceding piece changes the formatting, so
we ignore those.

At least, that's the intent. It turns out there's actually a bug and
the solver looks at the *last* piece on the *first* overflowing line.
That can lead to subtly different formatting when there are multiple
splittable pieces on the same line.

In practice, only one extremely weird test was affected. I suspect that
if we started running the formatter on larger code samples, we'd find
other more obvious mistakes.

This fixes that.

Author: munificent

lib/src/back_end/code_writer.dart

@@ -147,7 +147,9 @@ class CodeWriter {
 
     // If we haven't found an overflowing line yet, then this line might be one
     // so keep track of the pieces we've encountered.
-    if (!_foundExpandLine && _currentUnsolvedPieces.isNotEmpty) {
+    if (!_foundExpandLine &&
+        _nextPieceToExpand == null &&
+        _currentUnsolvedPieces.isNotEmpty) {
       _nextPieceToExpand = _currentUnsolvedPieces.first;
     }
   }

test/invocation/chain_postfix.stmt

@@ -136,9 +136,9 @@ someReceiverObject.method1().method2().method3()
 someReceiverObject
     .method1()
     .method2()
-    .method3()(
+    .method3()(argument)(
       argument,
-    )(argument)<T, R>(
+    )<T, R>(
       argument,
       argument,
       argument,