update-deps.py: Allow bazel_dep + archive/git_override

[npaun]

This PR adds a new flag to our existing dependency types for downloading packages:

• github_release
• github_tarball
• git_clone

If use_bazel_dep: true is set, we generate a bazel_dep() + an override directive (e.g. archive_override() or git_override(). Otherwise, we use the existing templates for a WORKSPACE based repo.

Additionally use_module_bazel_from_bcr: some.version.here can be used to automatically download an inject a MODULE.bazel file from BCR if one is available from there, but not in the project itself.

This is basically the last PR in my project of upgrading update-deps.py. There's probably still room for small simplifications / cleanups down the road, but the vast majority of our dependencies are now automated again.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will degrade performance by 84.24%

_{Comparing npaun/bazel-dep-with-override (59df4a3) with main (b73532d)}

Summary

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 157 untouched benchmarks
🆕 2 new benchmarks
⏩ 38 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	Existing_LargeStream_Value	12.3 s	77.7 s	-84.24%
🆕	bm_Coro_Fib10	N/A	20 µs	N/A
🆕	bm_Promise_Fib10	N/A	19.2 µs	N/A
⚡	simpleStringBody[Response]	22.1 µs	19 µs	+16.36%

Footnotes

1. 38 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[fhanau]

LGTM otherwise

[fhanau]

nit: No need to freeze the version per se, it's just that patches might break. Let's add a comment or unfreeze

[fhanau]

I wrote this comment, but it seems too pedantic in retrospect: If there are breaking changes, we will likely notice through our tests failing, and the downstream build will not be directly affected. We'll be able to clean up breaking tests as they happen, as with other dependencies. I guess we can reduce the comment to just say that this is expected to break tests more often than other dependencies?