Support ANSI commands when using xcodebuild

[jflan-dd]

My project is running into an issue where SPM isn't able to create a multi-arch binary similar to this one:
swiftlang/swift-package-manager#8013

While not quite the same issue, this forum post suggests using xcodebuild to resolve issues when building for multiple archs:
https://forums.swift.org/t/swiftpm-compile-multiple-arch-system-library/75724/3

Using xcodebuild resolved my issue, but it causes the #if Xcode check within supportsANSICommands to fail which breaks lots of things.

This PR checks the TERM environment variable instead, which Xcode sets to "dumb" to indicate that it doesn't support ANSI commands. Cursory searching online leads me to believe this is a common pattern to communicate inability to support ANSI commands.

Testing:
xcodebuild build -scheme ConsoleKitExample -derivedDataPath DerivedData -destination "generic/platform=macOS"
then
./DerivedData/Build/Products/Debug/ConsoleKitExample

[codecov]

Codecov Report

❌ Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.56%. Comparing base (b7854a8) to head (a7b9148).

Files with missing lines	Patch %	Lines
Sources/ConsoleKitTerminal/Terminal/Console.swift	40.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #214      +/-   ##
==========================================
+ Coverage   45.75%   46.56%   +0.81%     
==========================================
  Files          46       46              
  Lines        1906     1864      -42     
==========================================
- Hits          872      868       -4     
+ Misses       1034      996      -38     

Files with missing lines	Coverage Δ
Sources/ConsoleKitTerminal/Terminal/Console.swift	57.14% <40.00%> (-42.86%)	⬇️

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jflan-dd]

I was looking at the Bazel command documentation for an unrelated reason and saw that their "auto" color mode uses similar logic to this, but with a couple more cases.

If this option is set to auto, Bazel will use color output only if the output is being sent to a terminal and the TERM environment variable is set to a value other than dumb, emacs, or xterm-mono.

I'd be happy to update this PR to match that behavior if preferred.

[jflan-dd]

@0xTim or @gwynne, could one of you review this PR?

I don't think the PR check failure was caused by this change.