)

**What type of PR is this?**

Feature

**What does this PR do? Why is it needed?**

This moves the download of the "all versions" JSON, which can't hit the
repository cache, from each individual `go_download_sdk` into the module
extension. If the current version of Bazel supports facts, this
information will also be persisted in the lockfile, allowing for truly
airgapped builds assuming an up-to-date download (formerly repository)
cache.

This is a reland of #4393 with the following improvements:
* Adapted to the more limited facts API that actually got merged.
* Prefetching of SDK hashes is now performed on a best-effort basis so
that otherwise airgapped builds that provide SDK hashes do not result in
failures.

See bazelbuild/bazel#26198 for the PR that added
facts support to Bazel.

**Which issues(s) does this PR fix?**

Fixes #3945 

**Other notes for review**

You can verify that this works by running `bazel mod show_repo
@go_default_sdk` in the BCR test repo.

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

All of rules_go tests were failing on macOS Tahoe 26 due to `missing
LC_UUID load command` in the clang binary built and in other tools. Many
tools from Go to bazel itself have had to drop various workarounds for
these kinds of linker problems in the run-up to macOS Tahoe (see
bazelbuild/apple_support@44c43c715a and
bazelbuild/bazel#27014)

To fix this, we bump the version of build_bazel_apple_support (a.k.a.
apple_support in Bazel Central Registry) to 1.24.3 in WORKSPACE. We also
have to move the build_bazel_apple_support dependency above the
llvm_toolchain call in order to make sure that version is actually used.

It's possible we should also upgrade the llvm_toolchain to something
more modern to handle some of our deps problems. The current llvm used
by rules_go is 8.0.0 and is from 2019. The latest llvm version that
toolchains_llvm supports in its latest release 1.5.0 is llvm 21.1.0.


**Which issues(s) does this PR fix?**

Fixes #4499

**What type of PR is this?**

Other

**What does this PR do? Why is it needed?**

The .vscode directory isn't meant to be checked in like this, and causes
churn that vscode users have to remove before sending PRs. We remove it,
add it to .gitignore so future folks don't accidentally check it in.
Folks can check out the more general Editor setup wiki page for
instructions.

**Which issues(s) does this PR fix?**

Fixes #4497.

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

Also run all tests against the latest release candidate for each major
release to catch issues early.


**Which issues(s) does this PR fix?**

Work towards
bazelbuild/bazel-central-registry#6402

**Other notes for review**

)

**What type of PR is this?**

> Documentation

**What does this PR do? Why is it needed?**

And link from README.rst.

GitHub wikis seem to be downranked pretty hard by Google, so these
instructions haven't been very visible. Linking from the README should
help.

**Which issues(s) does this PR fix?**

n/a

**Other notes for review**

For some reason, the vim instructions were in docs/go/editors/vim.md
instead of in the wiki. I've squashed them into a new section here.

<!-- Thanks for sending a PR! Before submitting:

1. If this is your first PR, please read CONTRIBUTING.md and sign the
CLA
   first. We cannot review code without a signed CLA.
2. Please file an issue *first*. All features and most bug fixes should
have
an associated issue with a design discussed and decided upon. Small bug
   fixes and documentation improvements don't need issues.
3. New features and bug fixes must have tests. Documentation may need to
be updated. If you're unsure what to update, send the PR, and we'll
discuss
   in review.
4. Note that PRs updating dependencies and new Go versions are not
accepted.
   Please file an issue instead.
-->

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

Fix some Bazel matching issues on riscv64

**Which issues(s) does this PR fix?**

Fixes #4053

**Other notes for review**

The riscv64 architecture has been widely developed and adopted recently,
and optimizing support for riscv64 is very meaningful as it can provide
better riscv64 support for downstream users.

For example, when I was using `bazeldnf`, due to some limitations in the
current repository, I couldn't use `bazeldnf` directly. The specific
reason is this:
https://github.com/rmohr/bazeldnf/blob/main/bazeldnf/platforms.bzl. This
depends on the current repository's `BAZEL_GOARCH_CONSTRAINTS`, which
currently lacks riscv64 support, so the riscv64 version of bazeldnf
cannot be used directly. If this PR is merged and released, downstream
users will be able to get good riscv64 support.

A PR quite similar to this one is
#3336. I think the
situation with riscv64 is quite similar to that case. The Go upstream
also provides good support for riscv64.


**Other Info**
Co-authored by: nijincheng@iscas.ac.cn;

This is required for compatibility with bazel @ HEAD. Done with:
`buildifier --lint=fix -r .`