Add additional modules to module_ctx

### Description of the feature request:

I'd like additional properties on module_ctx.
* `module_ctx.root_module` would be an `Optional[bazel_module]` that would be equivalent to the output of the `_find_root` function below
* `module_ctx.current_module` would be a `bazel_module` object corresponding to the module that defined the current module extension (it could possibly be a `Optional[bazel_module]`.

A classic piece of code being written is:
```
def _find_root(module_ctx):
for mod in module_ctx.module:
if mod.is_root:
return mod

def _find_current_module(module_ctx):
for mod in module_ctx.module:
if mod.name == "rules_rust":
return mod
```

This would significantly simplify the recommended workflow we prescribe in https://github.com/bazelbuild/bazel/discussions/22024 (eg. https://github.com/bazelbuild/rules_rust/pull/2624)

### Which category does this issue belong to?

Core, External Dependency

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

Our discussion about the right way to implement toolchains in bazel came to the following conclusion:

The policy would be, for a given toolchain defined by rules_foo which has the tag `foo.toolchain`:

* If the root module defines a toolchain tag, the toolchain configuration will be:
* Configured based on the root MODULE's `foo.toolchain` tag
* Any unspecified fields *may* be inherited from `rules_foo`'s `foo.toolchain`
* Any specified fields *must not* be affected by `rules_foo`'s `foo.toolchain`
* The toolchain configuration *must not* be affected by any module other than the root module and `rules_foo`
* If MVS is supported, `rules_foo` *may* choose to compare the root MODULE's `foo.toolchain` with MVS(all modules' `foo.toolchain`) in order to output warnings
* If the root module doesn't define a toolchain, the toolchain is defined by:
* If MVS is supported, MVS(all modules' `foo.toolchain` invocations)
* Otherwise, `rules_foo`'s `foo.toolchain`
* Non-leaf modules *should* specify the minimum possible versions and minimal set of features in their `foo.toolchain`

This will require special-casing of the root module and the current module extension, both of which seems like something pretty reasonable to me.

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

linux

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

7.1.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` ?

_No response_

### 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 with module_ctx and the _find_root/_find_current_module examples, then read the linked discussion and rules_rust pull request for the intended toolchain workflow. Trace where module extension context and bazel_module objects are defined; done means root_module and current_module expose the agreed module objects or optional values, with behavior covered by tests.

Written by the indexing model from the issue text.