Our rust binaries (e.g. scip-ctags/syntect_server) were being built in some mix of opt & fastbuild mode[1]. Unlike with Go where there is no release/debug mode flag, Rust requires opting into optimized release builds. We can do that automagically when building any oci_image target with the power of ✨ transitions ✨

This has the side-effect of our Go binaries no longer being stripped & containing debug symbols, see bazel-contrib/rules_go#3917

Also to note, [in Cargo.toml we opt into debug symbols in release mode](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@nsc/bazel-release-mode-rust/-/blob/docker-images/syntax-highlighter/Cargo.toml?L67%3A11-70%3A9). Is this preserved by this PR for bazel[2]?

[1] `strings` on the binaries showed the 3rd-party crates having `k8-opt` filepath names e.g.
```
$ / # strings syntect_server | grep k8-
/tmp/bazel-working-directory/__main__/bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/crate_index__onig_sys-69.8.1/onig_sys_build_script_.runfiles/crate_index__onig_sys-69.8.1
```
but the final binaries (and the 1st-party crates) themselves were being built in fastbuild mode. See https://github.com/sourcegraph/devx-support/issues/790 for original point of contact

[2] It seems like it may be preserved, but I dont know how reliable this is for Rust binaries
```
$ file bazel-bin/docker-images/syntax-highlighter/scip-ctags
bazel-bin/docker-images/syntax-highlighter/scip-ctags: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, with debug_info, not stripped
```

## Test plan

Tested for sourcegraph/scip-ctags image:
```
/ $ strings scip-ctags | grep "Could not parse file"
/ $ echo $?
1
```

(cherry picked from commit ce6a366)