Adds cwd target from rules_multitool for linters

[orbl]

When devs use linting tools outside of bazel they get used to the pattern that the linting bin is aware of it's current working dir. However, bazel run isn't designed for this. To circumvent this rules_multitool exposes a target that is cwd aware. Given that rules_aspect_lint exposes the bin it would be helpful to also expose the cwd endpoint; so that devs that use this for linting can also use the exact same setup to run the linter outside aspects. I.e. by invoking the lint using bazel run //linterbin -- linter flags

I suspect this PR is incomplete, but I wanted to submit it to see if the addition is welcome at all. If yes; I can possible expand this to other targets that use rules_multitool.

---

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: no
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: no

[CLAassistant]

All committers have signed the CLA.

[aspect-workflows]

Test

All tests were cache hits

4 tests (100.0%) were fully cached saving 2s.

---

Test

docs

All tests were cache hits

15 tests (100.0%) were fully cached saving 672ms.

---

Test

example

7 test targets passed

Targets

//tools/format:format_test_JavaScript_with_prettier [k8-fastbuild]12s
//tools/format:format_test_Markdown_with_prettier [k8-fastbuild]2s
//tools/format:format_test_Protocol_Buffer_with_buf [k8-fastbuild]618ms
//tools/format:format_test_Python_with_ruff [k8-fastbuild]188ms
//tools/format:format_test_SQL_with_prettier [k8-fastbuild]2s
//tools/format:format_test_Scala_with_scalafmt [k8-fastbuild]4s
//tools/format:format_test_Starlark_with_buildifier [k8-fastbuild]262ms

Total test execution time was 21s. 27 tests (79.4%) were fully cached saving 7s.

---

Test (WORKSPACE) (Test)

example

7 test targets passed

Targets

//tools/format:format_test_JavaScript_with_prettier [k8-fastbuild]9s
//tools/format:format_test_Markdown_with_prettier [k8-fastbuild]2s
//tools/format:format_test_Protocol_Buffer_with_buf [k8-fastbuild]750ms
//tools/format:format_test_Python_with_ruff [k8-fastbuild]323ms
//tools/format:format_test_SQL_with_prettier [k8-fastbuild]2s
//tools/format:format_test_Scala_with_scalafmt [k8-fastbuild]6s
//tools/format:format_test_Starlark_with_buildifier [k8-fastbuild]258ms

Total test execution time was 20s. 11 tests (61.1%) were fully cached saving 8s.

---

Lint [.]      Lint [docs]      Lint [example]

[alexeagle]

Hi, thanks for the PR and the suggestion!

I think what we really want here is both an entry on the PATH for the developer to run on the command-line, but also a stable workspace-relative path so the editor linter plugin can be configured with a path to the tool.

I think following the example from https://github.com/buildbuddy-io/bazel_env.bzl/blob/main/examples/BUILD.bazel is a better way to achieve both of these. I added that link to https://github.com/bazel-contrib/rules_multitool?tab=readme-ov-file#running-tools-in-the-current-working-directory as well. What do you think?