Add "//visibility:testonly"

### Description of the feature request:

Add `"//visibility:testonly"` visibility specification.

Similar to `"//visibility:public"`, but only grants visibility to targets with `testonly=1` [attribute](https://bazel.build/reference/be/common-definitions#common-attributes).

Example:
```
# package //A
some_library(
name = "foo",
visibility = [
"//visibility:testonly"
],
)

some_library(
name = "foo_use",
deps = [":foo"], # error
)

some_library(
name = "foo_test_use",
testonly = 1,
deps = [":foo"], # allowed
)

some_library(
name = "bar",
visibility = [
"//visibility:testonly",
"//visibility:private",
"//C:__pkg__",
],
)

some_library(
name = "bar_use",
deps = [":bar"], # allowed via "//visibility:private"
)

some_library(
name = "bar_test_use",
testonly = 1,
deps = [":bar"], # allowed via "//visibility:testonly" (or "//visibility:private")
)
```

```
# package //B
some_library(
name = "b_foo_use",
deps = ["//A:foo"], # error
)

some_library(
name = "b_foo_test",
testonly = 1,
deps = ["//A:foo"], # allowed via "//visibility:testonly"
)

some_library(
name = "b_bar_use",
deps = ["//A:bar"], # error
)

some_library(
name = "b_bar_test",
testonly = 1,
deps = ["//A:bar"], # allowed via "//visibility:testonly"
)
```

```
# package C
some_library(
name = "c_bar_use",
deps = ["//A:bar"], # allowed via "//C:__pkg__"
)
```

Note that `"//visibility:testonly"` grants visibility to all `testonly=1` targets, not just ones in the same package: `//B:b_foo_test` can depend on `//A:foo` from another package.

Note that `"//visibility:testonly"` does not prevent `testonly=0` targets getting visibility by other means: `//C:c_bar_use` can depend on `//A:bar`.

### Which category does this issue belong to?

Loading API

### What underlying problem are you trying to solve with this feature?

Visibility lets us control how targets are used, to avoid the library being misused.

For some classes of misuse, we don't need to prevent certain types of library misuse in tests.
We only care about asserting this control over production code, not for test code.

For tests, we would prefer to have easier access to write the test.

The alternative to this is very long visibility lists, that typically mix testing an non-testing targets. Many tests want access, but only a few pieces of non-test code need access.

### Which operating system are you running Bazel on?

_No response_

### What is the output of `bazel info release`?

_No response_

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text

```

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

The issue identifies Bazel's Loading API and the common testonly attribute as the relevant entry points. Start by tracing existing visibility handling, then verify the documented examples: testonly targets may use testonly visibility across packages, while non-test targets remain restricted unless another visibility entry allows access.

Written by the indexing model from the issue text.