WASMTIME_LOG output emits ANSI sequences when redirecting stderr to file

[cfallin]

In #7239 we added a tracing-log subscriber that prints log output to stderr when the WASMTIME_LOG environment variable is set. This is useful for debugging, but unfortunately its ANSI color sequence heuristics seem somewhat broken: on Linux, if I run

$ WASMTIME_LOG=tracing wasmtime compile ... 2>log

I see a log file that looks like

    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
     Running `target/debug/wasmtime compile --target aarch64 -C pcc=yes -O static-memory-maximum-size=0 ./test.wat`
^[[2m2023-11-01T04:49:35.596710Z^[[0m ^[[34mDEBUG^[[0m ^[[2mwasmtime_cache::worker^[[0m^[[2m:^[[0m Cache worker thread started.
^[[2m2023-11-01T04:49:35.596813Z^[[0m ^[[34mDEBUG^[[0m ^[[2mwasmtime_cache::worker^[[0m^[[2m:^[[0m New nice value of worker thread: 3
^[[2m2023-11-01T04:49:35.600299Z^[[0m ^[[34mDEBUG^[[0m ^[[2mcranelift_codegen::timing^[[0m^[[2m:^[[0m timing: Starting Translate WASM function, (during <no pass>)
^[[2m2023-11-01T04:49:35.600374Z^[[0m ^[[35mTRACE^[[0m ^[[2mcranelift_wasm::func_translator^[[0m^[[2m:^[[0m translate(12 bytes, u0:0(i64 vmctx, i64, i32) -> i32 fast)
^[[2m2023-11-01T04:49:35.600595Z^[[0m ^[[34mDEBUG^[[0m ^[[2mcranelift_codegen::timing^[[0m^[[2m:^[[0m timing: Starting Compilation passes, (during <no pass>)
^[[2m2023-11-01T04:49:35.600669Z^[[0m ^[[34mDEBUG^[[0m ^[[2mcranelift_codegen::context^[[0m^[[2m:^[[0m Number of CLIF instructions to optimize: 12
^[[2m2023-11-01T04:49:35.600694Z^[[0m ^[[34mDEBUG^[[0m ^[[2mcranelift_codegen::context^[[0m^[[2m:^[[0m Number of CLIF blocks to optimize: 1
^[[2m2023-11-01T04:49:35.600716Z^[[0m ^[[35mTRACE^[[0m ^[[2mcranelift_codegen::context^[[0m^[[2m:^[[0m Optimizing (opt level Speed):

The code does indeed check whether stderr is a terminal before enabling ANSI sequences; but somehow this is not working right.