Quality of live improvements for working with module overrides

### Description of the feature request:

Many people working on multiple modules simultaneously will find it useful, if Bazel provided a command line feature to streamline working with module overrides. Bazel could provide a command of a following sort:

> bazel mod git_override some_git_url@git_rev

Working as following:
1. Fetch the git revision from some_git_url@git_rev into the temporary space.
2. Look for MODULE.bazel inside. If not found, bail out.
3. Update the `bazel_dep` entry in the current workspace with information from fetched module's `module` statement. If `bazel_dep` entry is missing, add it.
4. Add `git_override` statement for just updated module pointing to the fetched revision. If already present, update it.
5. Make the override unique, by erasing all other overrides possibly present.

Kind of similar to `go get`.

Same can be done for local overrides as well:

> bazel mod local_override some_path

As above: look if some_path contains a valid MODULE.bazel, update the relevant `bazel_dep`, add/update the relevant `local_path_override` entry. Make it unique by removing other overrides present.

For completeness, we can think of a command to quickly drop an override:

> bazel mod remove_override some_dep_name

Check if `some_dep_name` dependency has an override entry present. If yes, erase it.

Further enhancements: reserve an implicitly included file name dedicated to overrides (as those can get noisy), something like MODULE.bazel.overrides

### Which category does this issue belong to?

External Dependency

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

Registries are swell and all, but anybody who is working on a multi-module project often ends up in a situation where some issue may be arising due to a problem in the dependent upon code. Or, difficult issue may need to be diagnosed in depth. Or, there are intermediate fixes which are not ready to be published but have to be accommodated (feature branch work, etc).

All these cases are covered by the `override` family of workspace methods. And maintaining those quickly becomes very tedious, with the need regularly arising to comment/uncomment sections of the MODULE file, copy paste revisions and some such. All these are simple, but annoying tasks.

There are ways to work around those in the current system, but they are hacky and can be confusing:
1. Custom scripts which need to be maintained
2. Piggy backing on `go get` + Gazelle; actually a surprisingly useful technique, whereupon dummy go packages can be added to unrelated Bazel modules in order to trick Gazelle to auto-import them.

However, I believe that such tricks should not be necessary: Bazel has all the necessary functionality in its core; `bazel mod` can already edit MODULE files. The only thing missing is some helpful tooling to make a common development task less "ceremonial".

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

MacOS

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

8.2.1-homebrew

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

An example workflow for the feature, may be handy as further explanation. Let's say I have a project which depends on a module called fancy_trinket:

```
bazel_dep(name = "fancy_trinket", version = "1.0.0")
```

I want to accomodate the upcoming version of said trinket into my project:

> bazel mod git_override trinkets_git@v2-devel

Keep coding, oops, trinket has a bug in it:

> git clone trinkets_git@v2-devel ../trinket_devel
> bazel mod local_override ../trinket_devel

Fix the trinket, test the project, commit whatever, back to previous flow:

> bazel mod git_override trinkets_git@v2-devel-fixed

Done with the development, trinket released:

> bazel mod remove_override fancy_trinket

I think the above workflow is common enough to absolve developers from editing the MODULE file multiple times manually.

Start at the existing `bazel mod` MODULE-file editing functionality and review how module overrides are currently represented. Define the command behavior for git, local, and removal operations, including validation and uniqueness; done means an agreed design with implementation and test coverage for the proposed workflow.

Written by the indexing model from the issue text.