Bazel configuration to better enable dependent builds

[TristonianJones]

Disable cel.dev/expr gazelle build generation

Closes #1184

[TristonianJones]

FYI @fmeum @ouillie

[ouillie]

Here's an outline for how to verify if a solution will work for #1184:

Start by cloning @jarreds reproduction: https://github.com/jarreds/cel-go-repro.

Click for potentially superfluous details that might be helpful for understanding exactly what's happening.

As the README in that repo says, the problem surfaces when you introduce the bzlmod dependency on grpc then try bazel build cel-test. Looking at the output of bazel mod graph, the only chain of module dependencies that leads to cel-spec is grpc -> xds -> cel-spec. Looking at the only version of xds in BCR, you'll notice it's using a pretty old version of cel-spec (0.15.0). You can override this by adding bazel_dep(name = "cel-spec") to the repro's MODULE file (either with a version, or with a local_path_override). FTR, I just tested with the latest cel-spec version (0.25.1) and observed the same failure as with 0.15.0, but I did the rest of my testing with 0.15.0 anyway.

Then, clone cel-spec locally, check out tag v0.15.0, apply the patches listed for that version in BCR, and use a local_path_override in the reproduction repo to bring cel-spec in from this local clone.

Here's what I know: if you edit go.mod in the local cel-spec clone, and change the module name at the top to anything other than cel.dev/expr, the build in the reproduction repo should start working. For instance, it works when you change it to module cel.dev/exp (missing the final 'r'). I cannot confidently tell you why that works, but I laid out my suspicion in #1184 (comment). Basically, I think it has to do with Gazelle getting confused by conflicting definitions for a Go module called cel.dev/expr.

It's possible that entirely ridding the cel-go repo of the Gazelle dependency on cel.dev/expr would also fix this. I left a comment to that effect.