**What type of PR is this?**

> Bug fix

**What package or component does this PR mostly affect?**

> go_deps

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

The go_deps.from_file tag now accepts an attribute
ignore_local_replaced_modules. When set, a go.mod "require" is ignored
(no go_repository is instantiated) if it has a "replace" with a local
path in the same file.

This hushes a new warning caused by Gazelle's own abuse of the module
system: Gazelle has a single Bazel module but multiple Go modules. It
refers directly to packages in the v2 submodule without a repo marking,
for example, as "//v2/flag".

This flag allows opting into this behavior, since it may be a problem
that affects other Bazel modules with multiple Go modules, and it's
difficult to work around. It's opt-in to discourage wide use. Gazelle
should be able to clean this up once we can release proper v2 versions.

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

Fixes #2315

**Other notes for review**

Not sure it's possible to write a test for this. The warning popped up
with `bazel run :gazelle`, but it's only a DEBUG line.

**What type of PR is this?**

> Bug fix

**What package or component does this PR mostly affect?**

> all

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

This lets us drop the `replace` from go.mod, which is blocking `go
install` in #2319. And it more accurately represents how Gazelle is
managing dependencies: we'll need to do this anyway if `v2/go.mod`
requires something that `go.mod` does not.

This requires a substantial change in `go_deps`. I've renamed the
`bazel_deps` list to `bazel_go_modules` to reflect the fact that with
`go.work`, Bazel modules and Go modules are not one-to-one: a Bazel
module like `gazelle` may contain multiple Go modules. We should not
generate `go_repository` definitions for these, nor should we warn about
selected version differences.

Unfortunately, we can't ignore `go.work` files outside the main module.
Gazelle's `deps` labels refer to `//v2/...` packages within the same
module; clients cannot have a different view of the module boundaries.

This change means that we don't need `ignore_local_replaced_modules`, so
reverting that in #2321 since it's not released yet.

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

Fixes #2319

**Other notes for review**

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

When managing a large monorepo (or possibly a small, chaotic repo) it's
possible for the number of directives in build files (especially the
top-level build file) to become unmanageable, obscuring the actual
content of the build file in a mess of directives.

This adds a new `directive_file`, which is treated as if the directives
in it are inline with the build file. Recursion is forbidden (so you
can't use the `directive_file` directive in a directive file) to
simplify processing, both by machine and by people.

**What type of PR is this?**

Feature

**What package or component does this PR mostly affect?**

`rule` and `walk`

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

You've disabled issues in the GitHub repo....

---------

Co-authored-by: Jay Conrod <jay@engflow.com>