Add truecolor support detection for Windows Terminal

[cnlancehu]

Fix #193
Fix #180

[spenserblack]

Thanks! Overall looks good. I just have a bit of feedback.

[cnlancehu]

Finished.
I'm a bit foggy in the head at night. Sorry for that :)

[cnlancehu]

I am wondering if we can detect Windows Terminal by the environment variable WT_SESSION.
However, it is not an official API, so it might not work properly in some special cases.
Nevertheless, it is the easiest way to detect WSL in Windows Terminal.

[spenserblack]

Oh, sorry, this one slipped my mind. Any reason to close this PR?

[cnlancehu]

Sorry, I thought this wasn't planned. I don't think there's a perfect way to solve this problem right now.
This PR should be converted to a draft.

[spenserblack]

Here's what I'm thinking:

By default we just always enable true color support on Windows (like Deno). As time goes on, any Windows version that doesn't support color will be deprecated. Additionally, if we expose a flag to enable/disable true color support, we can leave it up to the users of this library to disable it on Windows devices, if needed.

There may not be a perfect way to do it, but I think this should cover the majority of users. In the linked issue it looked like you were using Windows Terminal -- is truecolor support also available for the other built-ins (command prompt, PowerShell)? We can deal with edge-cases (like people using 3rd-party terminals on Windows) when they show up.

I was actually thinking of merging this after doing some final touches myself. If the above sounds reasonable to you as a Windows user, I think we can move forward.

[cnlancehu]

My initial approach was admittedly driven by eagerness to address the immediate issue, and I appreciate you taking the time to refine the implementation.

Regarding Windows Terminal detection, as you mentioned, we could always enable true color support on Windows.

About the set override functionality, I'm thinking whether we need to modify some function names in the existing ShouldColorize in control.rs and make some optimizations. I want to put the truecolor support set override into control.rs, but there are already functions named set_override and unset_override, which makes it difficult to distinguish between TrueColorSupport and ShouldColorize.

I also want to add that this isn't just a Windows-specific issue. On Linux, we might encounter similar situations where some terminals support ANSI 256 colors but don't explicitly indicate truecolor support. In such cases, it would be more appropriate to convert truecolor to ANSI 256 colors rather than falling back to 8 colors, as this would provide a better color representation.

It will take some time to perfect these changes and ensure everything works as expected. Thanks.