Windows: Link MSVC dynamic debug CRT for debug builds

[akien-mga]

Fixes #31608.

Edit: See #69609, it's now opt-in behind the debug_crt=yes option.

Didn't test, please confirm if this works as expected.

See godotengine/godot-cpp#932 for a similar change in godot-cpp (CC @Faless).

And https://developercommunity.visualstudio.com/t/race-condition-on-g-tss-mutex-with-static-crt/672664 for a reference on the MSVC static CRT bug. Might be worth testing with newer MSVC to see if it's still broken.

[YuriSizov]

It seems this change has introduced a major regression in startup times (and perhaps performance?) for me. During the startup CPU gets to 100% utilization and it takes multiple times longer to get into any project, including an empty one.

I happen to use VS Code for C++ dev, and I have Godot Tools permanently enabled. With that startup times turn to a crawl. It takes a very long time to get to the splash screen, and then it is so slow to load beyond that I've been sitting for minutes to no avail. It will probably load, I can see activity in the logs, it's just sooo sooo slow. Seems like the language server is doing a lot of stuff on startup, which is multiplied by the regression from this change.

I use these flags to build Godot: platform=windows -j20 target=editor dev_build=yes. Switching to the previous commit in the master branch removes any slowdowns and removes 100% load on all cores for my 12/24 CPU.

[Zylann]

I don't know if this is related, but if you compile in debug mode, Godot can decide to compile shaders and that can last for several minutes using 100% all cores. That does not happen twice though, unless the cache gets invalidated.
It might not be related to the CRT itself though: maybe it's because third-party libraries (such as shader compiler and the standard library) now pick up the _DEBUG flag properly and do debug checks and compile differently, which leads them to be slower.
I guess it was faster before because those libs did not compile with debug checks at all in dev builds...