Add many more global analyses.

[Hixie]

• Catch trailing spaces and trailing newlines in all text files.
  Before we were only checking newly added files, but that means we
  missed some.

• Port the trailing spaces logic to work on Windows too.

• Correct all the files with trailing spaces and newlines.

• Refactor some of the dev/bots logic into a utils.dart library.
  Notably, the "exit" and "print" shims for testing are now usable
  from test.dart, analyze.dart, and run_command.dart.

• Add an "exitWithError" function that prints the red lines and
  then exits. This is the preferred way to exit from test.dart,
  analyze.dart, and run_command.dart.

• More consistency in the output of analyze.dart.

• Check that all widgets have a "key" argument.

• Add the "key" argument to the widgets that lacked them.

• Refactor analyze.dart to use the _allFiles file enumerating logic
  more widely.

• Add some double-checking logic to the _allFiles logic to catch
  cases where changes to that logic end up catching fewer files
  than expected (helps prevent future false positives).

• Add a check to prevent new binary files from being added to
  the repository. Grandfather in the binaries that we've already
  added.

• Update all the dependencies (needed because we now import crypto in
  dev/bots/analyze.dart).

[a14n]

nit: one line for this collection if

[a14n]

nit: one line for this collection for

[a14n]

There's a trailing \n here that is not L473 below

[a14n]

to avoid \n it could be

...errors.expand((String paragraph) => <String>[paragraph, '']),

or

for (String paragraph in errors) ...<String>[
  paragraph,
  '',
],

[Hixie]

Strictly speaking I don't know which is better... I've left the \n for now.

[dnfield]

Are we sure this doesn't break github's parsing of this file?

[Hixie]

no, not really. we'll find out pretty quick though. :-)

[dnfield]

Intended? Will this not break the decryption?

[Hixie]

This is just a test file.

[dnfield]

Isn't this O^6? Or is the compiler really able to fold these into a single test on one iteration?

[Hixie]

I would assume it's O(N), why would it be O(N^6)? Where is just a mapping iterator, it walks the incoming iterator, filters it, and only yields matching lines.

I don't think the compiler knows anything here, it's just how the iterator API is implemented.

[dnfield]

Sorry, it's not O(N^6), but it's close to O(N*6) (a bit shy of that since each iteration eliminates at least one element) - each of those where clauses has to iterate the entire yielded set from the previous one, and those first few are only eliminating one or two files a piece.

You'd save a bunch of iterations if this was just a single where with a larger path.basename(file.path) != ... &&, or maybe even just !file.path.endsWith(...) && !file.path.endsWith...

[Hixie]

This code runs in milliseconds, I'm not really that concerned about making it faster, certainly not at the cost of readability. :-)

[dnfield]

LGTM modulo the stacked where clauses