fix(build) assume a custom compiler will support --export-dynamic-symbol-list linker flag. (#16387)

This PR fixes a regression that caused deno binaries produced by the CI
release workflows to be larger than expected.

**The problem:** The build script will determine whether the linker
supports the `--export-dynamic-symbol-list` flag by looking at the glibc
version installed on the system. Ubuntu 20.04 ships with glibc 2.31,
which does not support this flag. Upon investigation, I discovered that
the CI pipeline does not use the gcc compiler provided by the
`build-essential` package, and instead uses *clang-14*, which does
support the new flag.

**The solution:** Whenever a custom C Compiler is configured, the build
script now assumes the compiler supports the
`--export-dynamic-symbol-list` flag. This is not always going to be the
case (you could use clang-8, for example), but it puts the onus on the
user making the override to ensure the compiler has support.

This will return deno builds for Linux to their previous size of ~100MB,
and also allow builds under older glibc/gcc versions to succeed. If a
user is compiling deno with a custom compiler that does not support this
new flag, however, their build will fail. I expect this is a rare
scenario, however, and suggest we cross that bridge if and when we come
to it.

cli/build.rs

@@ -361,7 +361,10 @@ fn main() {
   #[cfg(target_os = "linux")]
   {
     let ver = glibc_version::get_version().unwrap();
-    if ver.major <= 2 && ver.minor < 35 {
+
+    // If a custom compiler is set, the glibc version is not reliable.
+    // Here, we assume that if a custom compiler is used, that it will be modern enough to support a dynamic symbol list.
+    if env::var("CC").is_err() && ver.major <= 2 && ver.minor < 35 {
       println!("cargo:warning=Compiling with all symbols exported, this will result in a larger binary. Please use glibc 2.35 or later for an optimised build.");
       println!("cargo:rustc-link-arg-bin=deno=-rdynamic");
     } else {