Support --source in kernel compilation commands

[dcharkes]

https://dart-review.googlesource.com/c/sdk/+/231334 introduced passing additional sources to gen_kernel.

This PR enables passing additional sources to the various pub commands compiling kernel, so that these arguments can be passed from dartdev.

This PR depends on:

• Support --source in FrontendServerClient webdev#1760

[dcharkes]

❌ test/package_list_files_test.dart: with git with a submodule respects its .gitignore with useGitIgnore (failed)
  Git error. Command: `git submodule add ../submodule`
  stdout: 
  stderr: Cloning into '/tmp/dart_test_IEEKIJ/myapp/submodule'...
  fatal: transport 'file' not allowed
  fatal: clone of '/tmp/dart_test_IEEKIJ/submodule' into submodule path '/tmp/dart_test_IEEKIJ/myapp/submodule' failed
  exit code: 128
  package:pub/src/git.dart 65:7            run
  ===== asynchronous gap ===========================
  test/package_list_files_test.dart 279:9  main.<fn>.<fn>.<fn>

This seems to be unrelated to my changes.

@sigurdm

[dcharkes]

CI is red because of #3617.

[dcharkes]

Merging. This will turn CI red, which is tracked in #3617.

[dcharkes]

@devoncarew your previous DEPS CL looks suspiciously like an automatically generated CL. Is there a tool I can invoke to do the same? Or is it automatic? Might I suggest adding a link to the tool documentation in the commit messages of the CLs it creates?

Pub also needs a bump now in the sdk DEPS file to include this PR.

[devoncarew]

Yes, it is from a tool; we generally run the script (manually) 1-2 times per week. It's low enough cost in aggregate (per package) that I'm not too worried about further automation.

Anyone can run it (and is welcome to). It's just dart tools/rev_sdk_deps.dart from the sdk repo. That will use git and the gclient CLI tool to make edits to the DEPS file. You then create a CL from there as normal. We could add some additional tooling around it to automatically create a CL (as tools/manage_deps.dart does), but haven't explored that yet.

Pub is currently excluded from auto-bumping via this tool, as that team likes to update the SDK's changelog when they roll (the linter and dart_style are also excluded, for separate reasons).

Might I suggest adding a link to the tool documentation in the commit messages of the CLs it creates?

Sounds great; I'd take a CL that does that (in the tool's current form, that message would just be printed to stdout, and it would be up to the developer to copy the commit messages and that text into the CL's description).