Add support for describing "runnable" dependencies of a target

[chrisjrn]

Some languages supported by pants (Python and JVM notably) can produce targets that are executable only if their runtime is present. This means Pants needs machinery to make the runtime available in the sandbox for any target that the user wants to run.

The current art for this, adhoc_tool, supports providing a single target as its runnable. This obviates the need for e.g. giving the entry point a name, or differentiating between whether a target is being used as something that should be run, or something that is merely being used as runtime data.

One notable flaw in this approach is that multiple runnable targets cannot be provided. This prevents simple cases of composition in shell_command; it also prevents runnable targets from describing targets that will be invoked as subprocesses when run.

#18082 described the possibility of adding a runnable_dependencies field to the shell_command target. This is possibly acceptable as an experimental feature, noting that these dependencies could only be defined on the shell_command: It would not be possible to describe child runnable dependencies on targets that are themselves pulled in as runnable. This means that if there were multiple shell_commands using the same basic runnable, each of them would need to declare the runnable's runnable dependencies.

A better approach would be to be able to add runnable dependencies to the targets themselves, which would be brought in by pants run or shell_command or adhoc_tool.

The shell_command target's tools field could also be replaced with runnable dependencies, if shell tools were made available as runnable dependencies by way of Synthetic targets.

---

This ticket needs further design before implementation. The author believes this looks a lot like scoped dependencies (#12794), and a genuinely good design for runnable dependencies would probably fall out from solving scoped dependencies well.

[chrisjrn]

#18347 includes a lot of the machinery for introducing runnable dependencies into the sandbox (yay), but does not provide a good solution for:

• Flexibility of target names. If a runnable needs to call foo, the target that provides the /usr/bin/env foo must itself be named foo
• Transitive dependencies. If a runnable foo needs to call bar, every place where foo is run needs to declare bar as a runnable_dependency.

I lean towards a solution where you can tag the dependencies from within the dependencies field (as I attempted in an early commit in #18347), rather than adding in new fields: if a target is runnable, then it should be able to specify its runnable dependencies. Targets shouldn't have their utility limited by not being to run subprocesses because the plugin author forgot to add a field.