Tweak block argument heuristics

[munificent]

This produces output that better matches what users expected in the associated issues. I think it also looks better in the affected regression tests. And I ran this on a large corpus and looking at the diffs, these rules seem to be much better across the board.

The new rules are basically:

• A block formatted argument list can't end up with named arguments on multiple lines.

• Only one trailing argument is allowed after the block argument.

The existing rules are also kept:

• Prefer a function block argument over a collection one.

• Only allow a single block argument.

• Allow the first argument to be adjacent strings with a later function block argument (to handle calls like test() and group()).

Fix #1527.
Fix #1528.
Fix #1543.

[natebosch]

FWIW I'd be on board to recommend using named arguments anywhere to move named test and group arguments before the callback argument for the best formatting.

[munificent]

FWIW I'd be on board to recommend using named arguments anywhere to move named test and group arguments before the callback argument for the best formatting.

I should have mentioned this initially but I investigated this. I agree that it would be better for those named arguments to be moved before the lambda, but it turns out that it's still pretty common in existing code for those arguments to be trailing. I looked at all calls to functions named test(), group(), and testWidgets() in a corpus of pub packages:

-- Signatures (4126 total) --
   3312 ( 80.271%): ("...", () {...})
    459 ( 11.125%): ("...", () {...}, name: arg)
    173 (  4.193%): (arg)
     48 (  1.163%): (arg, arg)
     44 (  1.066%): ("...", arg)
     42 (  1.018%): (arg, () {...})
      8 (  0.194%): ()
      8 (  0.194%): ("...", name: arg, () {...})
      6 (  0.145%): (arg, () {...}, name: arg)
      5 (  0.121%): (arg, arg, arg)
      4 (  0.097%): (arg, arg, name: arg, name: arg, name: arg, name: arg, name: arg, name: arg)
      3 (  0.073%): ("...", () {...}, name: "...")
      3 (  0.073%): ("...", () {...}, name: arg, name: arg)
      3 (  0.073%): ("..\n..", () {...})
      1 (  0.024%): (arg, () {...}, name: arg, name: arg, name: arg, name: arg, name: arg)
      1 (  0.024%): (arg, arg, name: arg)
      1 (  0.024%): (arg, arg, name: arg, name: arg, name: arg, name: arg, name: arg)
      1 (  0.024%): ("...", arg, name: "...")
      1 (  0.024%): (arg, name: arg, () {...})
      1 (  0.024%): (arg, () {...}, name: arg, name: arg, name: arg, name: arg)
      1 (  0.024%): ("...", arg, name: arg, name: arg, name: arg, name: arg, name: arg, name: arg)
      1 (  0.024%): ("...", arg, name: arg, name: arg, name: arg, name: arg)

Over 10% of calls have a trailing named argument, so I figured it was worth allowing that directly to avoid disrupting code more than necessary.

[natebosch]

it turns out that it's still pretty common in existing code for those arguments to be trailing.

Yeah, there are a whole bunch from before named-arguments-anywhere was an option, and I suspect they get copy/paste often enough that many authors aren't even aware of the option. Making the formatter work well for the existing corpus sounds good.