Refactor: DRY adhoc_tool code_quality_tool

[gauthamnair]

Before moving to step 2 of the plan described in #17729 (comment) , cleaning up a gross duplication of rule code that I introduced in #20135 between adhoc_tool and the new code_quality_tool.

This PR extracts the shared logic into the concept of a ToolRunner and a rule to hydrate it in adhoc_process_support.

Both adhoc_tool and code_quality_tool have the latent idea of a tool runner and a considerable machinery to build it. Starting from something like

@dataclass(frozen=True)
class ToolRunnerRequest:
    runnable_address_str: str
    args: tuple[str, ...]
    execution_dependencies: tuple[str, ...]
    runnable_dependencies: tuple[str, ...]
    target: Target

they need to assemble things like locate the actual runnable by str and figure out what should be its base digest, args, env, etc. and also co-locate the execution and runnable dependencies. We now capture that information as a "runner":

@dataclass(frozen=True)
class ToolRunner:
    digest: Digest
    args: tuple[str, ...]
    extra_env: Mapping[str, str]
    append_only_caches: Mapping[str, str]
    immutable_input_digests: Mapping[str, Digest]

After this, adhoc_tool and code_quality_tool diverge in what they do with it. adhoc_tool uses this runner to generate code and code_quality_tool uses it to run batches of lint/fmt/fix on source files.

Food for thought ...

It should not escape our attention that this ToolRunner could also be surfaced as a Target, to be used by adhoc_tool and code_quality_tool rather than each specifying all these fields together. It would also help to reduce confusion when handling all the kinds of 'dependencies' arguments that adhoc_tool takes.

[lilatomic]

Looks good! I spotted that AdhocToolNamedCachesField doesn't seem to be ported over, though.

[huonw]

Nice one, thanks for waiting!

It should not escape our attention that this ToolRunner could also be surfaced as a Target, to be used by adhoc_tool and code_quality_tool rather than each specifying all these fields together. It would also help to reduce confusion when handling all the kinds of 'dependencies' arguments that adhoc_tool takes.

Yeah, I agree :) I think it matches with how I've noticed people interpreting adhoc_tool too: "here's a prepackaged command that could be invoked with pants run ... (or similar)". That is to say, it feels like that's potentially a very useful building block 👍

[huonw]

(I hit the "update branch" button to trigger a full CI rerun with latest code, since it's been so long, to avoid for "merge skew".)