Currently, we provide single-file tools such as ctags, gsutil etc via an sh_binary wrapper, to have a single target to reference that automatically does platform selection of the underlying tool.
Due to some unfortunate reason, the underlying srcs (which is a single file) of an sh_binary are also exposed as outputs (rather than just as typical runfiles) alongside the script that wraps. This is sometimes problematic when doing location expansion (e.g. $(location ...)) due to these only allowing a single output (dont ask why this works in some contexts but not others, I dont know).
To address this, we create a wrapper macro + rule to replicate what we want from sh_binary (automatic platform selection + tool naming), while only exposing a singular file.

See example of currently required approach to consuming a tool: BUILD.bazel & main_test.go.

With this change, rlocationpath (singular) can be used instead (or any of the other singular nouns in different contexts), as well as no strings.Split/strings.Fields being required

Test plan

bazel cquery --output=files //dev/tools:dropdb yields 1 vs 2 files.
Also updated the rule behind //internal/database:generate_schemas due to the workaround in it for the fact that the underlying srcs was also exposed. The correctness is verified by running said target (locally + CI)