Is your feature request related to a problem? Please describe.
For web programs, the launch is hard-coded to run using build_runner (I think, it's hard to tell) and tests are hard-coded to run using test. This causes various problems. For example tests that use builders would like to be run using build_runner test. It would be better to use webdev, and then options like --enable-expression-evaluation could be used. Many organizations have other tools they use. For example, we normally use dart_dev, which provides extra options and can be configured to be aware of organization or project-specific extra options, e.g. webdev_proxy. These issues could be fixed individually, but it can be hard to detect the right options, e.g. this PR. This could all be addressed by letting users indicate the tool. Configuration could be made easier by adding pre-defined configurations for the most common options.

Describe the solution you'd like
Add a launch.json option like "tool" to indicate the tool to be used. This would probably need to provide some kind of printf-style or $args-style substitution for arguments, because there's not much consistency between how tools that wrap others pass down arguments. e.g. build_runner test uses -- to indicate the end of build_runner args and the start of test args. dart_dev uses --build-args= and --test-args=. I'm sure there are other fun variations.

Describe alternatives you've considered
The obvious alternative is to handle the normal Dart ecosystem options directly, but this puts more burden on the extension to get the configuration right, and doesn't support custom tools. But it does make the configuration simpler for users.

Additional context
Add any other context or screenshots about the feature request here.