When I rewrote the format script, I forgot to filter out deleted files from the list of files that it looks at. This filters the file list to exclude deleted files
This converts the ci/format.sh script to a Dart script that uses process_runner and isolates to multi-process the clang-format, diffs, and grepping needed to do the formatting changes.
It also will (by default) only check the formatting of changed files.
The user can optionally check all files (--all-files) or do only some types of checks with --check. --verbose prints the versions of the tools used for Clang format and Java format.
Specifying --fix will cause any formatting errors that would have been detected to be fixed.
This cleans up the ci scripts so that they can be run from an arbitrary directory, and so that they don't have any bash lint issues, and are more explicit about which dart/pub/dartanalyzer executable they run.
I also fixed the format script to take a "--fix" argument that will fix all of the formatting issues found, including trailing whitespace and gn files.
I added a warning to the license script about untracked/ignored files in the fluttter repo because those so often trip up the license script.
I added missing license information to the ci scripts too.
There's now a bit of boilerplate at the beginning of each script (the follow_links function) in order to reliably find the actual location of the script: I'd put it into a common file, except that that code would be needed to reliably find the common location too, so I needed to duplicate it. It's the same boilerplate as what is used in the flutter/flutter repo for the flutter and dart scripts.
I deleted the ci/test.sh script, since it seems to be obsolete (the test it tries to run doesn't exist anywhere).
I got tired of waiting for it to run, so I added some of the "worker" queue code that I wrote for the assets-for-api-docs generator.
I also tried out putting all the files in one call to clang-tidy with the -p argument, but that was still a lot slower because it runs them all on one core. This runs separate jobs for each file, simultaneously, and then reports the results at the end (associated with each file, of course).
