Before bzlmod, repositories were global, and BUILD files inside upstream
repositories could load from the repositories defined at the root-level
WORKSPACE file.

With the introduction of visibility rules, these result in errors that
cannot trivially be worked around. One pattern that has emerged is
ignoring existing build files by specifying `gazelle:build_file_name
BUILD.bazel`, however this does not work for anything already using
BUILD.bazel filenames.

This does affect real-world users: an example is
github.com/google/go-jsonnet which has a BUILD.bazel file to `genrule`
its AST. The module is pure-go, but the build step contains cpp code,
and when imported under bzlmod-gazelle will not work because the cpp
code is invoked. As a workaround, there is now a 'jsonnet' BCR module.

This patch introduces a `build_file_generation = clean` option, which
removes existing build files before generating new ones. It allows
loading the jsonnet code once again, and also makes it possible to
load some of the complex protobuf repositories.

After my changes to remove build files as part of fetch_repo, I realized
that when urls=[] is specified the code path doesn't use fetch_repo at
all. In this case, fetch_repo_args would remain None, and raise an
error. Not ideal!

This left me with two general options: either I move the code into a
separate command invocation, or I have all code go through fetch_repo.

The latter seems to be the pragmatic solution: gazelle by itself doesn't
generate code with urls=[] (in either bzlmod or vanilla update-repos),
so it's the option with lower performance impact (also considering we're
stacking it on top of a network download).