Add dart run --find_entrypoint or similar

[natebosch]

With webdev and build_runner we're starting to investigate new use cases for tools which want to run binaries from other packages. We're looking at ways to avoid the cost of spinning up multiple VMs and have found some nice patterns using isolates - but when there are multiple packages involved we can't avoid the second VM because we need to use pub run package_name.

One way we've gotten around this with build_runner is to leverage an existing detail of it's design - that it puts a dart file on disk and runs it in an isolate anyway. We therefore have the cost of a second vm during pub run build_runner generateBuildScript, but only for a short time. That command prints out the location of the generated Dart file which can then be run in an isolate.

If we can do something similar with pub - run a quick command which prints the location of the binary - then we could set up new patterns of interactions between binaries in different packages, including those at the top level.

Forked from #1807

cc @nshahan @jakemac53

[nex3]

If this is motivated by performance, we should make sure that this would actually bring the gains you're hoping for. pub run has some sophisticated behavior around generating and caching snapshots that probably wouldn't be exposed here, which means that the pub run --find-entrypoint path would spend extra time parsing Dart files that. It also wouldn't really save you the cost of spinning up a new Dart VM, since that would have to happen when you invoked pub anyway.

I'm not inherently opposed to this--I think it would probably be generally useful to build something like npm ls or bundle show that tells users where they can find their packages, and showing executable paths in particular could be part of that--but I'd want to be sure it actually produced real improvements before investing a bunch of time into it.

[munificent]

It's less about performance than it is about being able to pass flags to the VM used to run your application independent of the flags used to run pub which then runs your application. It's nice to get that level of indirection out of the way so that you can use all of the options and environment variables the VM supports without affecting how pub itself behaves.

[sigurdm]

I think this would be cool to do for dart run. Resolving the package:executable logic. Do we also want to return the path to the relevant package config?

[natebosch]

Do we also want to return the path to the relevant package config?

I think so yes.

It will be more future-proof than having tools hardcode some assumption about the relative path between the binary and the package config which is what would likely happen otherwise.