Starlarkify sh_library

[fmeum]

Work towards #23658

RELNOTES[inc]: Only sh_library targets are permitted in the deps of sh_library rules. Other rules were previously permitted with a warning, but now need to be moved to srcs or data.

[fmeum]

@comius If you are happy with this, I can also take care of sh_binary.

[comius]

Nice thanks! Go ahead with sh_binary.

Internal rules are slightly different, @c-mita is working of them. But it shouldn't be a problem to eventually share the code.

If you haven't noticed, we also have a repo ready https://github.com/bazelbuild/rules_sh. This is where the code is eventually suppose to land...

[fmeum]

@aherrmann FYI about the name conflict with https://registry.bazel.build/modules/rules_sh

[aherrmann]

@fmeum thanks for the ping!

To add some context on the naming of https://registry.bazel.build/modules/rules_sh:

• The name was suggested by and agreed upon with members of the Bazel team (at the time) on a Bazel Skylib issue. We had initially intended to add the shell tools toolchain into Skylib, but creating rules_sh was agreed upon as the better option. Consider consistent naming between the ruleset and the rules tweag/rules_sh#1 discusses the full background on the name.
• The initial target for the toolchain was Skylib under bazelbuild, we had also discussed in the past to move rules_sh under bazel-contrib, though never got around to actually doing that. So, one way to avoid the naming conflict could be to merge the two instances of rules_sh. https://github.com/tweag/rules_sh provides a toolchain to import commonly used shell tools and rules to configure custom collections of shell tools and expose them to other rules like genrule, sh_binary, or others. There is also a corresponding Nix integration, but that lives inside of rules_nixpkgs and can stay there.