Exposing constants from MODULE.bazel to the rest of the build

### Description of the feature request:

MODULE.bazel doesn't allow loading variables from other files.

Other files (e.g. BUILD, .bzl files) can't load constants from MODULE.bazel, without going through a workaround where MODULE.bazel uses a repo rule to write a separate .bzl file.

These two together make it a little annoying to handle constants that should be shared between the MODULE.bazel file and other files in the build.

This is kind of similar to https://github.com/bazelbuild/bazel/issues/17114, but that issue ended up being solved by implementing support only for accessing the module name and version from the rest of the build.

Being able to load constants from MODULE.bazel in other BUILD files would solve this problem for constants other than the module name and version.

```
load("//:MODULE.bazel", "MY_CONSTANT")
```

Something like this was suggested here https://github.com/bazelbuild/bazel/issues/17114#issuecomment-1369845514

### Which category does this issue belong to?

External Dependency

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

I currently have a .bzl file defining a version string I'm currently loading in WORKSPACE for downloading an http_file, and then loading the same constant in a BUILD file that extracts the downloaded file and puts it into a docker container at a path determined by the name of the downloaded file. The BUILD file uses the constant to create symlinks to this variable path.

As an example, the constant may be "kafka_2.13-3.9.0". I use that name in WORKSPACE to download a "kafka_2.13-3.9.0.tar.gz", which I extract into the container from the BUILD file to e.g. `/some/path/kafka_2.13-3.9.0`, and then I use the constant in the BUILD file to create a symlink from `/some/path/kafka` to `/some/path/kafka_2.13-3.9.0`.

I'd like to be able to do something similar from MODULE.bazel without having to define this constant twice.

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

_No response_

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

8.2.1

### 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_

Start by tracing how MODULE.bazel is evaluated and how the existing module name and version are exposed to BUILD and .bzl files. Compare that path with WORKSPACE and repository-rule loading, then define tests showing constants can be shared without duplication; done means a constant from MODULE.bazel is loadable by other build files.

Written by the indexing model from the issue text.