Bazel: load rules_cc and rules_shell explicitly

[redsun82]

Turns out in #21371 I was right about java_* rules not relying on autoload anywhere, but it turns out some cc_* and sh_* rules still relied on autoload. This autoload is currently configured in the internal repository, but we want to remove it eventually. This patch:

• adds explicit loads to rules_cc
• removes an obsolete file (that depedency has its own bazel module since some time, we just forgot to remove the old file)
• add an explicit load to rules_shell

[Copilot]

Pull request overview

This PR ensures explicit loading of rules_cc rules to prepare for Bazel 9 migration by removing reliance on autoload. Similar to PR #21371 which fixed autoload issues for Java rules, this change explicitly loads CC rules from @rules_cc//cc:defs.bzl.

Changes:

• Added explicit load statements for cc_library and cc_binary rules in swift third-party BUILD files
• Removed obsolete BUILD.fmt.bazel file (fmt is now a proper Bazel module)

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
swift/third_party/BUILD.swift-llvm-support.bazel	Added explicit load for cc_library from rules_cc
swift/third_party/BUILD.picosha2.bazel	Added explicit load for cc_library from rules_cc
swift/third_party/BUILD.fmt.bazel	Removed obsolete file (fmt is now a Bazel module at misc/bazel/registry/modules/fmt/12.1.0-codeql.1/)
swift/third_party/BUILD.binlog.bazel	Added explicit load for cc_binary and cc_library from rules_cc

[esbena]

LGTM.
But I wonder why this wasn't caught back then.
Don't we have CI checks for when relevant build rules change?

[redsun82]

LGTM. But I wonder why this wasn't caught back then. Don't we have CI checks for when relevant build rules change?

@esbena These are only called by builds from the internal repo. There we were currently setting --incompatible_autoload_externally="+@rules_cc,+@rules_java,+@rules_shell" which effectively makes these change not required (for now). The Go problem is slightly different because there is a CI check running on this repo (but not blocking merges). Because of the above internal setting however also that didn't affect production. I didn't notice the failing CI check as it was swamped by expected CI failures from the internal repo (the bazel 9 update PR was a "depends on internal PR" one).

We still want to get rid of this all, as the next release of bazel will make --incompatible_autoload_externally a noop (and then this would break in production as well).